If you are about to build and/or have deployed phone verification or two-factor authentication (2FA) in your app or on the internet, then it is extremely important that you are aware of the threat of International Revenue Sharing Fraud (IRSF) also known as “Toll Fraud”. Fraudsters commonly target phone verification or 2FA flows with the goal of generating a high volume of voice calls or SMS to expensive destinations. Our simple diagram below illustrates how fraudsters can abuse your app to commit toll fraud. For a deep dive, learn more from our whitepaper.
Customer participation and shared responsibility are essential to successfully defend against toll fraud attacks. Our Verify and Authy products both include comprehensive built-in fraud detection and mitigation mechanisms. However, no provider-side solution can guarantee 100% effectiveness against sophisticated attackers using dynamic, constantly changing phone numbers and countries.
By implementing these simple safeguards to limit and restrict sending of one-time passcodes (OTPs) in your Verify deployment, you can greatly reduce the risk of toll fraud saving you much headache in the future.
1. Disable unused channels
If you don't plan to allow any calls, you can disable the channel at the service level in the Verify service console settings.
2. Use the following Verification Retry Logic in your application code:
- Use our Lookup API to identify if the phone number is a landline. Then if the phone number is not a landline phone number, require 3 time-delayed SMS attempts before allowing the voice OTP call option. You can find a more detailed example workflow on our Fraud Prevention blog post.
- If you cannot use the SMS channel and must rely on voice to verify a user, ensure you implement the recommendations below to mitigate abuse from a bad actor requesting voice OTPs.
- Make sure to include the logic in both your backend and frontend application code, not only in the frontend UI/mobile application code
|Good Example - “Call me instead” option is not visible until 3 time-delayed SMS attempts.||Bad Example - “Call me instead” option is visible at any time and can be repeatedly submitted.|
3. Set Rate Limits on requesting verifications
- Use Verify Service Rate Limits or build your own to proactively suppress and rate limit your verifications.
- Implement rate limits by user, IP, or device identifier. For example, 20 verification per hour per IP or 50 per day per IP. Web servers like Nginx and Apache support basic rate limiting through modules to prevent DDOS attacks. Standard security measures like this will raise the bar for an attacker.
4. Restrict Destination Countries by managing your own allow/deny lists
- If you only have customers in certain countries, you can restrict verifications to specific countries (e.g. “allow list”) by using the free Twilio Formatting Lookup to determine the country of the phone number being verified.
- Alternatively, you can disallow countries that you do not want to allow verifications based on the country of the phone number being verified (e.g. “deny list”).
- If you have data on the number of verifications you’d expect per day in a given country, you can set rate limits on groups of countries, allowing relaxed rate limits in countries where you expect legitimate users, and more restricted rate limits in all other countries.
5. Create Alerts
- Create internal monitors for conversion rate of verifications (Number of OTP Validated by end users / Number of OTP sent by end users) and verification volume. Having a spike in verifications to an unexpected country along with a sharp drop in conversion rate could mean you’re facing a toll fraud attack, but it can also mean you’re facing delivery issues.
- Configure a Usage Trigger on your account to alert you when your usage goes above a certain threshold.
6. Analyze IP
- Analyze IP location, IP owner (ISP/proxy/TOR/cloud provider, etc), and IP against the bad reputation list. Block TOR/Cloud Providers/proxies/bad IPs.
7. Implement CAPTCHA in the backend
- Implement CAPTCHA for voice calls, define thresholds when you should ask for them. For example, after the first or second unverified request.
If you’re interested in learning more, check out the resources from Twilio below:
Everything You Need to Know About Toll Fraud (White Paper under Voice and Phone)
Fraud Prevention with Twilio Account Security (Blog, 2019.0603)
Anti-Fraud Developer Guide (Dev Docs)