When we talk about authentication codes, what are we talking about?



Nowadays, it is more and more common to login with mobile phone authentication code. Although it will increase the cost, it will be helpful to improve the user experience. So, when the product manager tells the developer to sign in with a SMS authentication code according to the prototype. What should we think about as R&D?

What Short Message Login Should Do

The diagram here shows only one successful process. There are still many details worth discussing. In addition to the process of SMS authentication, the security of login must also be taken into account. Especially the more important background projects.
Next I want to take apart the 17 steps in the diagram.

Request for authentication codes (1-4)

There are two main points in step 1-4.

  1. The front-end validates the format of the phone number and the button’s multiple clicks
  2. Back-end restrictions on the frequency of requests for authentication codes

Verification rules can be relaxed. Although the front-end verification is not reliable, it does not mean that the front-end verification is useless. At the same time, when you click the button to get the authentication code, you need to disable the button to prevent multiple clicks.
The back-end part needs to determine whether the current IP is a duplicate request authentication code or not. Here we need to introduce the rule of duplicate request validation code. The general rule is that requests can be made again within 60 seconds. This time can be recorded by a key called a cache requesting the phone number, expiration time is 60 seconds. If you can get the value, it means that you haven’t requested it again in 60 seconds.

Verification of Legitimacy (5-8)

5-8 steps are mainly to verify the legitimacy of the users behind the mobile phone number.
First of all, the format of mobile phone number must be judged, although the front-end has judgement. But back-end verification is reliable. The latter is through mobile phone number database. The main logic of the query is

  1. Does the registered user have this cell phone number?
  2. Is the user status disabled
  3. Can this user right log on to the current business?

If the conditions are met, we can proceed to the next step.

Making/Storing Verification Codes (9-10)

Two problems must be considered when making verification codes.1 is the length of the verification code 2 is the complexity of the verification code
The most user-friendly, of course, is pure numbers. The shorter the authentication code, the better. But this is a big discount to security. Is there a user-friendly and secure solution?
The answer is yes.
First, we assume a four-digit solution. If there is no limit on the number of attempts, hackers can use multi-threaded tools to enumerate all the possibilities in a short period of time by violence up to 10,000 times, and their luck is not necessarily so bad. It could have been tried out 3,000 times.
So our solution is. Verify the same cell phone number three times. The validation code will fail. After three failures, the fourth request returns the error text “three successive errors in the validation code, please retrieve the short message validation code”
There is another dimension to think about. That’s the validity period of the SMS verification code. Generally speaking, short message validation codes are valid for 5 minutes. There will be a cross-cutting problem. For example, a user gets a validation code without validating it, and after 60 seconds he gets it again. He will have two valid validation codes. This is obviously unreasonable, so I need to discard the first verification code when I get the second verification code. When using cache to store validation codes, direct set can override the previous validation codes and reset the validity period for 5 minutes.

Finally, there is another problem that can easily be ignored. That’s it.Short message anti-brushOur previous settings were just for the brush protection of a cell phone number. Another kind of text brushing is the one that constantly changes the phone number to brush. The solution can determine whether the request is initiated by the same client through parameters such as ip, ua, referer, header and so on. If the same client requests more than five times in an hour. A graphics verification code must be entered. There is no need to say much about the implementation of graphic verification code. Too many bags to use directly. In this way, we can prevent others from attacking our system as much as possible, and at the same time, we can ensure that the experience is not discounted.

Send authentication codes to users (11-12)

This is a relatively simple step. Simply according to the interface document of SMS, the mobile phone number, the SMS template and the verification code can be sent. Consider adding a log to the database for data analysis.

Verify login, login success (15-17)

Authentication login is mainly to complete the previous step mentioned. Verification fails three times and discards the validation code (whether it matches or not). After the validation passes, the validation code should also be discarded. At the same time, it is necessary to verify the user’s legitimacy again after the validation code has passed. Prevent extreme situations, such as requesting authentication codes when the user is legitimate, but within five minutes the user is disabled. In that case, he can’t log in.
If the login is successful, it depends on the design of its own architecture. It can be a token token or a session session session. After the session is established, even if a complete SMS authentication code is logged in! ~


After the summary is completed, it can be developed according to the requirements. Although it is a simple SMS verification code, but I found many projects in the market, this piece is not well done (don’t ask me, how do I know Haha). As R&D personnel, we must be as considerate as possible to avoid online accidents.

Wechat Public Number: Richard Talked