11

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?

John L.
  • 741
  • 5
  • 8
  • 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). – theabhinavdas Aug 22 '16 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. – Adam Shostack Sep 21 '16 at 18:07

3 Answers3

2

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.

stuffy
  • 156
  • 1
  • 6
0

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.

DKNUCKLES
  • 9,237
  • 2
  • 37
  • 47
sebastian nielsen
  • 8,779
  • 1
  • 19
  • 33
  • Re: "user will send SMS to your service" — do you have any details about how easy/difficult it is to spoof the sender number? (https://en.wikipedia.org/wiki/SMS_spoofing) – Joel L Jul 23 '16 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. – sebastian nielsen Jul 24 '16 at 09: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. – theabhinavdas Aug 22 '16 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. – sebastian nielsen Aug 22 '16 at 22:33
  • I love the ReCaptcha solution, thanks – ucMedia Dec 30 '20 at 12:49
0

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

Briandotcom0
  • 1
  • 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 Apr 20 '17 at 08:42