I am thinking of using mobile phone number verification for the sign up step in my web application but how do I prevent a hacker or a malicious user from sending mobile verification requests to an unlimited number of phones? It would cause damage in a number of ways. It would consume my SMS package, thus costing me money plus preventing sign up of legitimate users. It would also cause inconvenience to those who would receive these text messages.

I thought of IP blocking but I think that would not stop a distributed attack and it would block legitimate users from that IP. I thought of using a CAPTCHA but that is not very convenient for mobile users and even though it will slow down the attack by a ratio, it will not be enough to completely prevent it.

How do websites like Facebook, Google, Microsoft etc. deal with this?

  • You realise that if someone had to exhaust your SMS package (say, 100k SMS's), then they would script something to automate the process and definitely not do it manually. So, they need a bot. And captchas are great ways to prevent such a DoS. It will not only slow down the attack, but also force the attacker to go manual, which is a huge pain. (Unless he breaks your captcha system though, hence - go for Google's captcha). Commented Aug 22, 2016 at 17:37
  • What problem are you trying to solve with "verification"? At the simplest level, why not just let people sign up for accounts in app without any verification? Knowing this helps assess what the right security measures would be. Commented Sep 21, 2016 at 18:07

3 Answers 3


Something that you might consider is a cool down period for an IP after it requested the SMS verification. This would not solve a distributed attack as indicated in the question but would to a large extent limit the effect of a single origin attack. The effectiveness of a distributed attack would also be reduced to some extent.

Although this might not be the best or final solution to your problem it is something to consider as an additional layer of your security.


Large websites deal with this by volume. They have such as large SMS packages, basically "unlimited SMS", so even a thousand of malicious SMS's won't "bite" on them.

For smaller sites, it's usually better to have a request-response system instead. There's 2 things you can do:

Either, you have a premium SMS number, and charge the equivalent fee that is cost for you to send the SMS; 5 cents for instance. Normally with operator fees and everything added up, it will result in a final fee for the end user of like 0,1 $ per SMS. This is the safest solution, as the signing up user must send a SMS from his phone to your service to receive a one-time "sign up" code or authentication code, and then the solution will become basically free for you (except for the monthly fee).

The other solution is to use reverse-charged SMS's. This means that you use a package that allows you to send "reverse charged" SMS's such as the receiver pays for the SMS. This usually means that the customer's operator will charge the SMS in their fee, thus the fee paid by the customer will vary with the operator customer uses. The problem with this is that some pre-paid cards do not allow reverse-charged SMS's at all (as this can result in the card going negative). The second problem is that if the service is used maliciously, it will result in users getting charged for SMS's they didn't request, so limit this accordingly, like 1 SMS per 7 day and phone number.

Adding Google recaptcha will prevent automated requests and also works on mobile, but it won't prevent manual malicious requests.

  • Re: "user will send SMS to your service" — do you have any details about how easy/difficult it is to spoof the sender number? (en.wikipedia.org/wiki/SMS_spoofing)
    – Joel
    Commented Jul 23, 2016 at 12:02
  • @JoelL - Thats why you reply with the code in question. Like "send SIGNUP to 72550" and then they get "Your signup code is XXXXXX". Tying mobile number to account is as easy to tie the code to the mobile number in a database. The idea behind sending a request, is that its the sending user that get charged for the SMS, and thus even if somebody spoof the number, its not a big problem, it will be like <10 SMSes that are spoofed number. Commented Jul 24, 2016 at 9:09
  • @sebastiannielsen, do you have statistics that you base your <10 spoofed SMSes on? :) The op clearly mentions websites such as Google, Facebook etc. Also, this is not spoofing IMHO. It's merely someone lying on a registration page. Commented Aug 22, 2016 at 17:35
  • @0x23212f What I meant is that any spoofed SMSes will result in the code being sent to the real un-spoofed number, so it wont matter. So there will just be a few ones that spoof the number just to harass but no more. Commented Aug 22, 2016 at 22:33
  • I love the ReCaptcha solution, thanks
    – ucMax
    Commented Dec 30, 2020 at 12:49

If its a possibility, give them the code on your webapp and have them text it to you instead of the other way around.

  • 4
    I'm not sure this satisfies the basic function of using SMS as a 2nd factor. One can spoof the sending phone number, which means I can verify as you if I know your number
    – schroeder
    Commented Apr 20, 2017 at 8:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .