3

building a server for an app and one of the steps of the registration in the app is to enter a phone number verification code. The verification code will be sent to the phone through sms and the verification code needs to be entered to continue the registration

The app will send a request to the server and is it possible for someone to find out the url and keep sending fake phone verification code requests to the server? How do you prevent the attack?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62

2 Answers2

2

I assume you are doing this to confirm that the phone number that is being registered is real and belongs to the person who is registering.

Scenario 1:

-Legit user registers

-Legit user receives an sms

-Legit user sends the verification code to server

If code matches the one that was sent then activate the user

Scenario 2:

-Attacker registers

-Attacker does not receive an SMS because he entered a phone number that is not his.

-Random person receives the SMS

-Attacker starts DoS against verification server and tries to guess the code.

The DoS problem in this case can be solved with simple block after X failed attempts. For example, store each failed verification attempt into a table and when there are 5 failed attempts for an account, block the verification for X minutes. This is similar to failing to login with username and password several times. The verification code must have enough possible combinations so that a brute force attack is not viable.

The other problem is that your service could be used to spam random people with the verification SMS. You'd have to limit registrations per IP per X time interval or something similar. You could also use captcha to prevent automated registrations.

Scenario 3:

-Attacker registers

-Attacker entered fake phone number so nobody receives the SMS

-Your SMS server get's delivery failure of SMS so nothing really happens. The verification code that was used to send the SMS is invalidated.

I hope this was somewhat helpful and I understood your intentions correctly.

cen
  • 2,873
  • 3
  • 31
  • 56
  • It is this scenario 3 that I'm worried about. Even though entering a random number won't help attacker to register, it will waste my SMS quota, since I'll be using a paid SMS service that will charge me even if the number is random/incorrect. – dotNET Jun 21 '18 at 21:11
  • @dotNET perhaps you could first require email verification and only after that you send the SMS. This way it would be harder to DOS you. You could also rate limit accuont creation per IP. – cen Jun 22 '18 at 09:14
  • Yep. That second line I'm taking. Can't use e-mail address since most of my users won't have one. :) – dotNET Jun 22 '18 at 12:51
  • Cool, thanks for the idea. I will set a max number of attempts (10 times) for each IP, if failure time exceeds the max number, the IP will be banned for 24 hours. Each successful operation will reset the attempt counter. – MewX Sep 19 '18 at 11:42
1
  1. Use a CAPTCHA to prevent automation.
  2. Limit frequency verification requests for a single number, ideally using exponential backoff.

Don't forget that the verification endpoint also needs securing; you must limit the number of attempts for a given verification code or use a long enough verification code such that it doesn't matter.

malthe
  • 1,237
  • 13
  • 25