OTP Bypass Security Issues and Remediations

In this article we will discuss how OTP flow works and what are the possible techniques to bypass and get those fixed as a security engineer.

What is OTP?

OTP stands for One-Time Password as the name demonstrates OTP is usually a 4–8 digit randomly generated numeric/alphanumeric password valid only for once and expires if not used within the time limit (which mainly ranges from 30 seconds to 15 minutes).

OTP Authentication flow?

OTP is mainly used as a part of 2FA (2nd factor authentication), 2FA is useful in case your credentials are leaked due to a breach and prevents an attacker from accessing your account/details by sending an OTP through SMS/Email.

SMS/Email based OTP mechanism utilizes the user’s phone number or email to send them a one-time password for authentication. Target site where a user is trying to authenticate tells the integrator to send an OTP to the user’s phone number or email, on receiving the OTP, user then inputs the same into target site and the OTP gets verified at server-side and based on verification access is granted.

This includes the following steps:

1. Target site asks the user to enter the phone number or email, which is already registered with the integrator/authMechanism (e.g. Truecaller).
2. User enters a phone number/email.
3. Target site triggers the integrator by calling sendOtp method to send a OTP to the user.
4. The user receives the SMS/Email with the OTP.
5. The user then enter the OTP and the same is verified by calling verifyOtp method thus authenticating the user.

Potential Security Issues?

Security issues can arise in case of both sending as well as verifying the OTP and not only while verifying!! Let’s discuss all the possible issues or weakness that can arise right from implementation stage.

1 OTP Generation (Predictable OTPs): If the OTPs are generated using a predictable algorithm insecure random number generators, attackers may be able to guess the valid OTPs.

2 Insufficient Entropy: If the entropy (length) used in generating OTPs is insufficient, it increases the likelihood of OTPs being guessed or predicted.

Best Practice: Use crypto graphically secure random number generators (CSPRNGs) to generate OTPs with high entropy (at least 6 digits) e.g. using java.security.SecureRandom method instead of java.util.Random in Java. Avoid using simple algorithms or predictable seeds for OTP generation.

3 OTP Delivery Risks (Man-in-the-Middle Attacks): Attackers may intercept OTPs during transmission if they are sent via insecure channels, such as unencrypted emails or SMS.

Best Practice: Deliver OTPs through secure channels, such as encrypted emails, SMS, or dedicated OTP delivery services.

4 Long-Term Validity: Allowing OTPs to remain valid for extended periods increases the window of opportunity for attackers to compromise them.

Best Practice: Implement short-lived OTPs with a limited validity period around 5 minutes to minimize the risk of misuse.

5 Disclosing OTPs in response: This is very important point to not disclose OTP in sendOtp response and directly send OTP to concerned mobile/email. Attacker can enter any mobile number and get the correct OTP in the response itself , thus leading to Account Takeover.

Best Practice: Always send OTP directly to concerned mobile/email.

6 Tampering with mobile_number/email/user_id: On successfully submitting the OTP against your email/phone, capture the success response and notice if there is mobile/email or any kind of user_id and try to replace those with someone’s else and see if you are able to log in into someone else’s account.

7 Tampering response body or status code: There might be a case in case of verifying/validating OTP, response body just says {success:true/false}, {Verified:yes/no} {allow:0/1}. In these cases, give any random OTP and try to manipulate response from false to true, 0 to 1 along with status code (from anything (4xx/5xx) to 200 OK) and notice if you are able to bypass the backend check.

We can also try changing the “400 Bad Request” to “200 OK” and the “incorrect OTP response” to “OTP Verified Successfully”.

8 OTP leakage in critical files: Tools such as dirbuster or dirsearch can be used to discover critical or unprotected files/directories and look for some JS/Php/txt/sqlite/db etc. files to check if any of the files stores OTP in plaintext against phone/email/user_id and the same can be used to do ATO (Account take Over).

9 Reusing or lack of rate limit: There should be proper rate limit on verify OTP functionality to prevent guessing the same using brute forcing attacks and also a proper check on same OTP should not be used more than once. Ideal rate limit should be 3–5 rq/min and account lockout policy after 10–15 unsuccessful tries.

10 Using master OTP or null to bypass: Try looking for page source and check the front-end code and also comments and see if there is any master OTP disclosed by mistake or trying with 0000 (null) or something similar as some times developers keep 0000 as by default OTP for stage testing and forgets to disable the same on production.

11 Parameter Pollution attack: While sending verify request, try adding 2 phone numbers instead of one (1 of victim and 1 of attacker) and analyze if both numbers are getting verified with only 1 right OTP of victim.

NOTE for developers: Always implement OTP verify logic at server-side and not at client side as it is extremely easy to bypass the same by using any proxy tool like burp-suite.

Implement rate limit on sendOtp method as well as company have to pay SMS charge against each OTP sent to user and moreover it can also lead to SMS DOS attack to user in case of no or very relaxed rate limit.

Always properly store OTP verify response status against email/phone and userId at backend to prevent fooling from response manipulation by an attacker or also generate some kind of secret/token against that user_id so as attacker can’t guess the same for victim while manipulating the response.

in this case changing false to true for verified will not work as attacker should be knowing secret (may be authToken and access_token as well) as well against userId and mobile number

NOTE for all: Always enable the option of masking OTP/Passwords and other critical information on lock screen on your device to prevent stealing of the same from nearby people as many people keep there phones on desk and anyone sitting near you can send any OTP to your phone and get the same from lockscreen if not hidden. (Go to SMS app’s App Info or settings, then manage Notifications, and then choose to hide from lock screen).