OTP Vulnerabilities

Kapil Verma
4 min readAug 18, 2021

Disclaimer: This blog is just for educational purpose so that our security researcher and developer can secure our online community by understanding the vulnerabilities and implementing proper mitigation.

In today’s world everything we do on the internet requires Authentication.

And in ancient days, It was “username:password” way of doing it, then came the new world where we use OTP.

OTP means One Time Password, What If this One time password is no so “One Time Password”?

Well, There are several ways the developers may miss certain logics to check while the implementation of this OTP.

Let’s List those flaws down and then discuss one by one seperately.

  1. OTP reusability.
  2. OTP Brute Force.
  3. OTP Bypass.

So, Let’s dive into the details of the above vulnerabilities from security perspective.

  1. OTP Reusability: In this case the OTP once used, doesn’t expire and we can use the same otp to login again even.
  2. OTP Brute Force: In this case the OTP can be brute force using any automated tools may be burp or any script to try all the possible OTPs, though this looks like a very long process but with licensed version of some tools this can be achieved very quickly, using multithreading.
  3. OTP Bypass: Well this is a little tricky case and it can be different in every application. I have personally found out more than 3 ways to bypass OTP.

How to bypass OTP(Few Examples):

  1. In some application the developer completely relies not on the OTP sent by the user but on the response sent by the server. Okay Let’s discuss in detail with example: Suppose the application sends OTP 1234, but the hacker doesn’t know the OTP, right? but using a proxy tool he will intercept the response and modify the response with the response that he received when he tried his actual mobile number and actual OTP. In some cases it’s very easy, the response with wrong OTP will be like below:

But, the Hacker will easily change the false flag with true.

Well, May be it can get tricky, In some cases the server might also be checking some other parameters like, content length etc,. So, It’s a manual approach and different depending upon the various developers.

2. Okay, Let’s discuss another way, It was a recent incident where I kind of used OTP reusability vulnerability to brute force, but It was tricky.

So, This application was actually checking the OTP unlike the first example.

But, the trick here was every time when I resent the OTP, I received the same OTP and it said it will expire in 15 minutes, but here was the catch. When I used the same OTP from the app, it worked but, if I used the same OTP from the repeater tab in my Burp suite tool, with the old OTP Validation request, It said OTP expired, Now I had to check what was the variable here if the OTP remained constant, yet somehow the server isn’t allowing me to authenticate.

Upon thoroughly checking the request, there was one parameter, that was changing and that depended upon the value which came in response when we hit the Resend OTP API.

So, To summarize, First hit the Resend OTP API and then get the parameter from response and the use that to brute force. And after every 3 attempts we need to change that parameter that we received from Response from Resend OTP API.

So, I just wrote a python script that will hit the try all the numbers from 0000 to 9999 but after every 3rd attempt it will hit the Resend OTP API, get the parameter from response, use that parameter with the next 3 attempts, and repeat the process for further 3 attempts.

It will be like below:

First get the parameter and use that to send OTP validation API and try 1111, 1112, 1113 then hit Resend OTP API, get the parameter value, use that to send the OTP Validation request and try 1114, 1115, 116 until you get 200 Ok response and as soon as you get the 200 ok use that parameter and OTP to login.

So, OTP Bypass it a bit tricky but the developers may surprise you with their coding skills every time.

Best practice, related to OTP are as follows:

  1. Implement OTP expiry.
  2. Implement OTP client and server side verification not just Response verification.
  3. Discard the OTP after 3 or 5 wrong attempts and send a new OTP all again for trying again.

That’s All Folks!

--

--