How to prevent someone from swiping the verification code?

The registration/login designed by Keng products allows you to obtain a mobile phone verification code, but it does not include a graphic verification code. And now our interface for obtaining verification codes has been swiped many times. There have been thousands of requests in the last hour, and they are all from different IPs and different mobile phone numbers....

Please give me some advice. In addition to adding a graphic verification code, how can I prevent swiping?

Reply content:

The registration/login designed by Keng products allows you to obtain a mobile phone verification code, but it does not include a graphic verification code. And now our interface for obtaining verification codes has been swiped many times. There have been thousands of requests in the last hour, and they are all from different IPs and different mobile phone numbers....

Please give me some advice. In addition to adding a graphic verification code, how can I prevent swiping?

All I can think of, except graphic verification codes:

1. Based on the mobile phone number, a maximum of N verification codes can be sent per mobile phone per day. It seems that LZ has already added this.

2. Based on IP, limit the maximum number of N verification codes sent per IP per day... -- Disadvantage: It is easy to accidentally kill normal users, use with caution

3. 【Ultimate method】Based on big data analysis of user behavior

How to analyze based on user behavior? I thought of a simple method:

First of all, in addition to sending the verification code request, normal users should also access other resources on the page, such as CSS/JS/HTML/images, etc.

However, if it is a brush, he may not specifically access these resources.

So when the user accesses the page, a human parameter can be recorded in session, and whenever the user requests a resource on the page, human += 1. When the interface sends the verification code, take out the human parameter and see what its value is. For a normal user, the human value should be greater than a certain value (such as 5), and if it is less than Just the brush. (The one for 0 is definitely a brush)

---

I said it is relatively simple. For more complicated ones, you can record the interval between several requests, the movement trajectory of the mouse before clicking the login or registration button, the time when the mouse is pressed and closed, etc., and record them for comprehensive analysis.

It would be great if you could quote or copy a reCAPTCHA like Google's - which automatically identifies people or machine brushes with just one click.

Like New Wolf Microwave~ Only when the username and password exist, the verification horse will be sent.

---

The problem is that you cannot add a password when logging in via mobile phone verification code. You can fill in the registered password casually, it doesn’t mean much

@locatejoe

Instead of displaying the password, the user name and password are taken as MD5 values, spliced ​​together, hashed, and mapped to a filter similar to bloomFilter.
bloomFilter returns that does not exist and the verification horse will not be sent.
bloomFilter does not take up much space and is very fast.

Already encountered this problem before

More than 20,000 messages were logged in 2 days

Solution:

1. Add graphic verification code
2. Determine the same IP and the same phone can only send 3 messages in a time period (although not friendly)
3. Determine the text message sending time. If the same phone and IP are used within 30 minutes, it will not work. Send

Anyway, there are many ways. Just give it a try

If it is a different IP and mobile phone number, then you can add the graphic verification code. . .

• Add graphic verification code, don’t make the font color too single.

• After a text message is sent, there needs to be an interval. The front-end cookie determines and PHP stores it separately

• The interface needs to determine the requested IP address and mobile phone number. If the time interval from the last time is too short, sending is not allowed