How can I prevent unauthorized verification codes?

The mobile phone verification code can be obtained for registered login, but the verification code is not added. Now our interface for obtaining verification codes has been frequently used. There have been thousands of requests in the last hour, and they are still different IP addresses and different mobile phone numbers ....... the mobile phone verification code can be obtained for registration/login designed by the product, but the verification code is not added. Now our interface for obtaining verification codes has been frequently used. There have been thousands of requests in the last hour, and they are still different IP addresses and mobile phone numbers ....

How can I protect against fake scams in addition to graphic verification codes?

Reply content:

The mobile phone verification code can be obtained for registration/login designed by the product, but the verification code is not added. Now our interface for obtaining verification codes has been frequently used. There have been thousands of requests in the last hour, and they are still different IP addresses and mobile phone numbers ....

How can I protect against fake scams in addition to graphic verification codes?

In addition to the graphic verification code:

1. Based on the mobile phone number, a maximum of N verification codes can be sent to each mobile phone every day. This seems to have been added to LZ.

2. Based on the IP address, limit each IP address to send up to N verification codes per day... -- disadvantage: it is easy to mistakenly kill normal users, use it with caution

3. [Ultimate means] Big data analysis based on user behavior

How to analyze user behavior? Think of a simple method:

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

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

Therefore, you can recordhumanParameter existssessionEvery time a resource in the request page ishuman += 1. When the verification code interface is sent, obtain thishumanParameter to check the value. a normal userhumanThe value must be greater than a certain value (for example5), Which is smaller than the brush. (0It must be a brush)

What I'm talking about is relatively simple. more complex, you can record the interval between several requests by the way, and move the track of the mouse before clicking the login or registration button, click and collapse the time to record the comprehensive analysis.

If you can reference or copy a reCAPTCHA like google, click it to automatically identify people or machine brushes.

Like xinlang microwave ~ The verification Trojan is sent only when the user name and password exist.

The problem is that using the mobile phone verification code to log on to this function cannot add a password. It doesn't make much sense to enter the registered password.

@ Locatejoe

Instead of displaying passwords, you can splice the MD5 values of both the user name and password, hash them, and map them to filters similar to bloomFilter.
BloomFilter returnDoes not existThe verification Trojan is not sent.
BloomFilter occupies little space and is fast.

I have encountered this problem before.

More than 20 thousand pieces of information have been refreshed in 2 days.

Solution:

1. added a graphic verification code.
2. determine that only three messages (although unfriendly) can be sent to a mobile phone with the same ip address within a period of time)
3. determine the SMS sending time. if the SMS is sent by the same mobile phone or ip address within 30 minutes, it will not be sent.

There are many ways to try it.

If it is a different ip address and mobile phone number, you can add a verification code...

• Add a graphic verification code. the font color is not too single.

• After a text message is sent, it takes time to determine the front-end cookie, which is stored separately on the php side.

• The API must determine the IP address and mobile phone number of the request. the request cannot be sent because the time interval is too short.