Protection against OTP abuse

The first factor identification with any internet application happens through sign up functionality and if there is a requirement to associate the user with phone number for the apps like e-commerce, food delivery, medicine delivery, events lookup etc, then the Signup is programmed to happen to OTPs.

Since any and every user is expected to produce OTP while signing up, the feature as such should not be bound by any security headers. This makes the OTP generation and delivery of OTP SMS vulnerable to an array of attacks like

1. DDoS attack - No further SMSes can be sent when the allocated SMS threshold for a given time for an application from the SMS service provider is reached due to increased requests.
2. Resource exhaustion attack - Exhausting allocated cost per unit time for sending SMS due to DDoS
3. Unintentional sending of SMS to customers that lead to annoyance and even to unregistered customers



Some of the counter measures to stop the abuse

1. Rate limiting - Both phone no. and IP wise
When the requests are received more than a no. of times from the same phone no. or from same ip for different phone no.s then they should not be served.

2. If same ip is sending OTP requests, though they are repelled, the ip should be blacklisted as the rate limit will hold good for a certain time range and the ip again becomes a valid ip after some time

3. Captcha is good option which looks for a valid recaptcha token in all the requests and these tokens are dynamically generated. The cons is that it obstructs the UX on the mobile apps

4. Use of invisible captcha which sends the captcha token and the captcha score along with the request. The score is based on the ip of the device where the request originates. Say this score is 0.9 for a genuine user.  If a same device is generating many requests, this score becomes less and less with every request. Say 0.7.  There will be a threshold score that the application has set in its server and (May be 0.8). If the score that request bring in lesser than the threshold score, then the requests are rate limited later on

5. Posing the recaptcha only when the requests attempts exceeded the number defined by the application.

6. Using a device-id which uniquely identifies the user's device in the request. There can be rate limits on this one as well where the check for device-id being associated for more than 2 phone no.s is blacklisted or rate limited.

7. Checking for proxy, tor requests and blocking them all together.

8. The phone no.s can be encrypted before using them in the requests so that attacker do not know the exact phone no.s. The phone no.s can be modified with a combination of hashing, salting, concatenating with time stamps etc so that it becomes difficult for the attacker to guess the 10 digit phone so it can be enumerated.

9. Finally there are apps and solutions that help you protect against the OTP abuse. They make use of machine learning and look up the global data bases for threat posing ips and actors and block them for your application. Few of the examples are Alibaba cloud Web application Firewall, Cloudfare solutions, Akamai solutions.

Please let me know your thoughts in the comments.


Sources:

https://www.ijert.org/research/sms-based-one-time-password-vulnerabilities-and-safeguarding-otp-over-network-IJERTV3IS051538.pdf

https://security.stackexchange.com/questions/184619/prevent-against-otp-abuse-in-app-sign-up-flow?rq=1

https://ringcaptcha.com/voice-sms-otp-resource-exhaustion-attacks

Comments

Popular posts from this blog

Bug bounty - Simple tips and tricks

Hashing, Salting, Encoding and Encrypting

Homomorphic encryption