How to Mitigate Interception of TOTP via Compromised Voicemail
Time to read: 3 minutes
It’s common to use a phone number as part of a user’s profile to increase confidence that the account is not fraudulent, and also to implement two-factor authentication (2FA) to help reduce account takeovers. However, any authentication or verification mechanism will attract attackers who will try to abuse it, and they get very creative when it comes to legacy technologies that use telephones.
Twilio offers two APIs which are designed to simplify phone verification (Verify) and two-factor authentication (Authy). Both APIs support the ability to verify or authenticate users via a phone call. This article explains how voicemail can be abused for these use cases and how Verify and Authy provide protection against attack.
Voice TOTP
Time-based one-time passwords (TOTPs), temporary passcodes used to authenticate users, are commonly used for 2FA. Even if a user's primary password is compromised, an attacker cannot gain access to the application without the TOTP, which changes every 30 or 60 seconds.
With Authy, there are various methods available for the user to receive a TOTP, including:
- Hardware security tokens, which display the password on a small screen
- Mobile apps, such as Authy and Google Authenticator
- Text messages sent via SMS
- Voice calls
Voice calls are the only way to deliver a TOTP to a landline, giving users the ability to access authentication requests and 2FA codes without the need for a mobile device. This channel of 2FA is important to ensure wide coverage of the different type of users that might need to access your application. To make this work, the user registers a phone number and then at the time of login, an automated voice call delivers the TOTP code verbally, allowing them to authenticate.
But what happens if the user doesn’t answer the phone to receive the TOTP?
Voicemail Problems
Voicemail systems have long been prone to attack. Implementing simple password controls and lacking protection against brute force attacks, making them a ripe target for attackers to abuse and gain access. Many users choose simple 4 digit passcodes, but even with 10 digits, passcodes can be hacked if voicemail systems do not lock after a number of failed attempts.
Both the Verify and Authy APIs have implemented features to mitigate against these vulnerabilities by requiring additional user interaction. Before going into those details, let’s look at using a voice call to verify a user has access to the phone number and then the attack:
- A user provides their phone number they want verified.
- The application creates a 6 digit one-time-use token via TOTP.
- The application calls the user’s phone number & reads out the one-time-use token.
- The user enters this token into the application.
- The application verifies that the user-entered token matches the generated token.
If the user does not answer the phone, the call will likely go to voicemail and the calling system might then read off the TOTP code. If an attacker compromises the voicemail system, they can time an attack where they request a token, have it delivered to the user’s voicemail, and then listen to the message and use the token to illegitimately use that person's phone number.
Mitigations
If you have built your own solution for phone verification or 2FA, there are two general options to avoid this attack.
Option #1 Have the system say “Press One” when the user answers and only read the token after the user takes the requested action. But if the prompt is predictable, the attacker can simply record a voicemail greeting to play the predictable DTMF code. Randomizing the prompt mitigates this risk.
Option #2 Use Answering Machine Detection (AMD) to detect if it’s a person or machine. Unfortunately, answering machine detection and other machine-learning solutions are, today, only somewhat reliable and may take several seconds to detect the answerer. This can create a frustrating user experience that causes them to hang up.
Twilio Mitigation
It’s a constant battle to keep up to date on the ways that attackers can get around your verification and authentication systems. The Verify and Authy API have a team of engineers and security professionals that are always looking to address new vulnerabilities.
When you use Verify and Authy, and a user answers the phone call with the TOTP, they are asked to press one random digit. The TOTP code is read out only after the user has pressed the appropriate digit. This makes it more difficult for an attacker to use the voicemail greeting to trick Twilio.
Final Thoughts
There are limitations to using voice calls for authentication.
This is why we’re seeing increasing adoption of 2FA using push authentication which employs end-to-end encrypted communications between the app and our secured authentication service, providing high-level security controls while also remaining easier to use than the other methods for 2FA.
This issue highlights the complexity and ever-changing landscape of implementing phone verification or two-factor authentication. Building this all yourself can often seem simple, but the long-term maintenance is daunting. We highly recommend using our Verify and Authy APIs so you can have confidence in the long-term account security for your customers. Want to learn more? This video is a great way to understand all the benefits of these types of APIs versus just writing all the code from scratch.
Related Posts
Related Resources
Twilio Docs
From APIs to SDKs to sample apps
API reference documentation, SDKs, helper libraries, quickstarts, and tutorials for your language and platform.
Resource Center
The latest ebooks, industry reports, and webinars
Learn from customer engagement experts to improve your own communication.
Ahoy
Twilio's developer community hub
Best practices, code samples, and inspiration to build communications and digital engagement experiences.