Most products will involve the user interface of SMS verification codes, especially mobile phone products. SMS verification codes have become the standard for almost all mobile phone products. Therefore, preventing text messages from becoming a concern for every product manager and developer.
Product managers who have not experienced the problem of text messages being brushed may not pay too much attention to this problem. In this article, I will briefly introduce the SMS Bomber with Black Tools. SMS Bomber is a software that uses written procedures to swipe a lot of text messages. It can automatically submit mobile phone numbers in batches, simulate IP, etc.
Therefore, when designing products that require SMS verification codes, restrictions must be formulated to prevent text messages from flashing.
In the PC era, most platforms reduce the risk of being brushed by machines through the form of graphical verification codes. The most typical example is 12306 "Wonderful Verification Code". However, in the era of the mobile Internet, user experience is very important, and sometimes the use of graphic verification codes will have some impact on the user experience. So, besides the way of graphic verification code, what other methods can solve the problem of sms being brushed?
Several schemes are provided for reference only: the ideas are in place, and the code is easy to implement
1. Time limit: Send again after 60 seconds
Starting from sending the verification code, the front end (client) will perform a 60-second countdown. Within this minute, users cannot submit multiple requests to send information. Although this method is commonly used, it is not very useful. People with better technology can bypass this restriction and send SMS verification codes directly.
code show as below:
//Check if sent after 60 seconds
$limitKey = "mobile_sms_send_limit:" . $mobile;
$smsSendLimit = Yii::app()->redis->get($limitKey);
if ($smsSendLimit) {
$this->_end(1, 'Resend SMS verification code after 60 seconds!');
}
2. Limitation of mobile phone number: the same mobile phone number cannot exceed 5 within 24 hours
When registering with the same mobile phone number or sending SMS verification code for other operations, the system can restrict the mobile phone number. For example, only 5 SMS verification codes can be sent within 24 hours. If the limit is exceeded, an error is reported (for example: busy, please try again later). However, this can only avoid brushing text messages manually. This method does not help for computers that send SMS messages in batches using different mobile numbers.
code show as below:
//Check the number of sending
$key = "mobile_sms_send_times:" . $mobile . ":" . date("YmdHis");
$smsSendTimes = Yii::app()->redis->get($key);
if (empty($smsSendTimes)) {
$smsSendTimes = 0;
} else if ($smsSendTimes >= 5) {
$this->_end(1, 'Each mobile phone can send up to 5 text messages per day!');
}
3. SMS verification code limitation: send the same verification code within 30 minutes
There is another method online: within 30 minutes, all SMS verification codes sent are the same verification code. Request the SMS interface for the first time, and then cache the SMS verification code results. If you request again within 30 minutes, you will return directly to the cached content. For this method, it is unclear whether the SMS interface provider will charge a fee for sending cached information. If you are interested, you can find out.
Part of the code is as follows:
<?php //Here to determine whether there is a text message cache if(Cache::get('codeCache') != null){ //If the text message exists for 30 minutes, the user will continue to send the same text message to the user. $code = Cache::get('codeCache'); //Next, send the code to the user's business operation }else{ //Receive SMS verification code $code = $this->smsTplTrait() //Suppose I receive the text "562334" as //Store the received code in the cache for 30 minutesCache::put('codeCache', $code, 30); } ?>
4. Front-end verification: Submit token parameter verification
This method is relatively rare, and I personally think that this method is worth trying. When the front end (client) requests to send a short message, it also submits a Token parameter to the server. The server verifies the Token parameter. After the verification is passed, it sends a short message to the user's mobile phone through the interface that requested the short message.
5. Uniqueness restriction: WeChat products limit the number of requests for the same WeChat ID user
If it is a WeChat product, it can be identified by WeChat ID, and then the user of the same WeChat ID is restricted, and only a maximum of 10 text messages can be sent within 24 hours.
6. Product process limitation: step by step
For example, in the case of registered SMS verification code usage, we divide the registration step into two steps. After the user enters the mobile phone number and sets a password, the next step is to enter the verification code verification step.
7. Graphic verification code limitation: After the graphic verification is passed , it is simple to request the interface
graphic verification code. The front-back interaction process is mainly divided into the following three steps:
1) When the client requests the page, it initiates a request to the server. The server generates a verification code and stores the verification code character in the session for the client's verification. At the same time, the server sends the generated verification code graphic to the front end;
2) The front end obtains the verification code graphic and renders it to the page. After the user recognizes the graphic verification code, the character of the verification code is submitted to the server;
3) The server receives the verification code verification request, compares the received character with the verification code character stored in the session, and compares The results are returned to the front end.
Front-end part of the code
<p class="form-group col-lg-6">
<label for="id" class="col-sm-4 control-label"> Code: </label>
<p class="col-sm-8">
<input type="text" id="code" name="code" class="form-control" style="width:250px;" />
<img id="imgObj" alt="ValidationCode" src="/article/getValidateCode" οnclick="changeImg()" />
<a href="#" οnclick="changeImg()">Change one</a>
</p>
Backend code
<?php
/ **
* Here is to determine whether the obtained code is consistent with the code of the existing session. If they are the same, go to the next step and send a text message verification code.
* 1 The first thing to deal with is that the front end needs to get the code from the back end to respond to the past, so the PHP back end must have the code that generates the verification code, generates the session, and responds to the front end.
* 2 After the front end gets the code, compare it with the session
* /
public function checkCode(Request $request)
{
$code = $request->input('code');
if($code == SESSION['getCode']){
//Here is the business logic for sending a short message after passing the verification code, according to your business needs
$consignee_content = $this->smsTplTrait('consignee_order', 1); //Find SMS Template
$consignee_content = sprintf($consignee_content);
$this->sendSmsTrait($consignee_content, '', 1); //send messages
}else{
response(['status'=>'0' ,'message' => 'Wrong verification code, cannot send SMS']);
}
}
?>
8, IP and cookie restrictions: limit the maximum number of IP / Cookie information
Using cookies or IP, you can easily identify the same user and then restrict the same user (for example, you can only send up to 20 text messages within 24 hours). However, cookies can be cleaned up, IPs can be simulated, and IPs can have the same IP in a local area network. Therefore, when using this method, consider the specific situation.
code show as below:
//Check the number of IP transmissions
$keyIp = "mobileIp_sms_send_times:" . PublicFunHelper::getIP() . ":" . date("YmdHis");
$smsIpSendTimes = Yii::app()->redis->get($keyIp);
if (empty($smsIpSendTimes)) {
$smsIpSendTimes = 0;
} else if ($smsIpSendTimes >= 20) {
$this->_end(1, 'You get SMS verification too often, please try again later!');
}
9. SMS warning mechanism to protect against problems
The above methods may not completely prevent the text messages from being brushed. Therefore, we should also implement a good early warning mechanism for short messages, that is, when the amount of short message usage reaches a certain amount, send an early warning message to the administrator, and the administrator can immediately monitor and protect the short message interface.