Every time when user wants to login to my service it sends one time password (OTP) to the user's phone number, then this OTP is used to confirm login.

Someone uses my service to bombard people with sms notifications.

I already implemented various blocks:

  • no more then 1 OTP per phone number per minute
  • no more then 5 OTP per IP per minute

What else can I do? Will captcha work?

  • Do you already check if the number provided does not belong to some premium-rate telephone number? Nov 2 '20 at 19:42

Consider the use of dynamic IP address blocking - I have a good amount of success with the following two free services:

The following command uses curl to connect to the AbuseIPDB, authenticate with the account token, and then download the result, with various parameters set according to the API documentation

curl --fail --write-out '\nCURL_%{http_code}+'$(date +'%Y%m%d%H%M%S') --silent --tlsv1.2 -H "Key: 7d467ef655e91e7db69f2078df1b0c2ccefb8eedc0372e9187b0d211aa1f336b73271e145f12aebc" -H "Accept: text/plain" -d countMinimum=15 -d maxAgeInDays=5 -d confidenceMinimum=90 -G https://api.abuseipdb.com/api/v2/blacklist

I access these services periodically, to extract the contents in the database, and create blocked ip address records as files within a tiered directory structure on the file-system: /OCTET1/OCTET1.OCTET2/IP4ADDR (dotted decimal). If the entry already exists, I touch the file again to update the metadata. Over time, this builds into a useful database.

Note to self: edit this answer to include the bash commands that prevent unbounded growth of the blocked ip files db...

In the context of Litespeed webserver running on Cloudlinux, I use .htaccess files to check to see if the remote ip address exists in a file on the file-system (representing a blocked address).

SetEnvIf Remote_Addr  '([0-9]{1,3})\.'              USR_RADDR_ONE=$1
SetEnvIf Remote_Addr  '([0-9]{1,3}\.[0-9]{1,3})'    USR_RADDR_TWO=$1

ErrorDocument 410 'Your IP address exists in an automated blacklist: connection refused.'
RewriteCond /etc/._ipblock_rbl/%{ENV:USR_RADDR_ONE}/%{ENV:USR_RADDR_ONE}/%{REMOTE_ADDR} -f 
RewriteRule ^ /e410_deny_%{ENV:USR_RADDR_TWO} [G]

I can't take credit for this idea, which stops about 50% of our traffic at the gate, and hasn't resulted in a single complaint to request unblocking, in nearly two years of production use. I wish I could find the reference to the source, a European(?) German(?) author of a .htaccess help site ?? If anyone knows, could you please edit or comment? thanks!


Rather than trying to solve the problem, you could kill the problem. SMS is no longer considered secure anyway, at least for sensitive functions.

Ditch SMS and offer your customers a choice of 2FA solutions available on the market today. Most people have a smartphone but for those who don't, you may still keep SMS OTP. And then, in this scenario you could consider captcha as a mitigation technique. The point is, not every account has to be enabled for SMS. You can provide alternatives.

The fact that spammers are able to trigger SMS storms means they already have some information like a username perhaps. Is there anything you can do to address this issue ?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.