Let's say I have a website which uses 4 digit OTP based authentication for login i.e. users will enter their mobile number, receive OTP on the entered mobile number, enter the received OTP to login successfully.

I have an approach on how to crack such a login based mechanism if I have access to a subset of all registered mobile numbers, and I want to know whether it will work and if yes how to protect against the same.

Let's say I have a list of 100,000 mobile numbers registered/using such a website.

Now, I will do the following process multiple times.

  1. Pick a previously unused phone number from the list of registered phone numbers.
  2. Hit the service to send an OTP to the registered phone number ( which I do not have access to ).
  3. The website in background will generate a random OTP and send it to the registered mobile number.
  4. I will generate a random 4 digit OTP and try to login using the same.

Now, the probability of the above process succeeding is: 10000 / (10000 * 10000) => 1 / 10000, because in every process a pair of 10,000 faced dice are rolled, and above is the probability that both of them will have same number on the top.

So, if I repeat the above process at least 10000 (expected value to get a match) times, I should be able to login using at least one phone number with high probability.

How do I mitigate such an attack ?

  • This is looking more like a maths problem than a security problem since you are trying to work out the probabilities in isolation of all the security controls that would be in place.
    – schroeder
    Sep 28, 2020 at 8:47
  • @schroeder , That's true, but you can assume that probabilistically speaking I will be able to crack in 10,000 tries, are there any solutions to prevent that. Are there any good solutions to prevent that. I am asking because there are lot of sites which use 4 digit otp for registration and login. How do they mitigate such attacks. Sep 28, 2020 at 13:42
  • Then you might need to include all that in your question.
    – schroeder
    Sep 28, 2020 at 14:23
  • @schroeder , I have updated the question accordingly. Sep 29, 2020 at 4:37

2 Answers 2


It doesn't matter how many mobile phones you have, each attempt still has 1 in 10000 chance of succeeding given a 4-digit PIN. What's important is how many attempts you have, which might not be tied only to a specific phone number but also to where the request ia coming from. This is one way to mitigate such attacks. Another is increasing the complexity of the OTP code, which is strongly encouraged in this case because 4 digits is definitely not secure enough if not paired with another for of authentication (username/password). Ideally introduce letters as well.

  • The only reason I am using multiple phone numbers is because there might be rate limiting on the number of attempts using a particular phone number. And, I wouldn't be able to make 10,000 attempts for a particular number. Sep 29, 2020 at 4:40
  • Also, if you attribute requests to a particular IP and rate limit on the basis of that, then it is certainly not a great way, because I might use different IPs. And, you cannot blacklist a particular IP, because generally ISPs use dynamic IPs and a particular blacklisted IP might be assigned to a genuine user in the near future. Sep 29, 2020 at 4:43

Yes, the proposed authentication scheme is not sufficiently protected against guessing the OTP code. Even if the OTP code is random, it is still only four digits, which gives a significant chance of guessing correctly.

There are several ways to protect against this:

  • Require another authenticating method, such as a password, before sending the OTP code.
  • Increase the size of the OTP code, both in length and possible characters.
  • Use rate-limiting, a captcha, or IP address blocks to prevent attackers from performing many guessing requests.
  • 1
    Can you explain elaborately how rate limiting can be used to mitigate this ? Sep 28, 2020 at 13:44

You must log in to answer this question.

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