Reduce SMS 2FA Risks By Using Device Data
Time to read: 3 minutes
Using SMS for 2FA security has recently been getting a legitimately bad rap, with a significant increase in successful attempts to intercept or redirect the 2FA codes sent via SMS as part of a login. We’ve addressed these issues (and more) with updates to the Twilio Authy API; making it possible to bypass sending SMS-based 2FA for a more secure, and less costly, authentication. The API now sends enhanced information from devices to allow you to make risk-based decisions for users authenticating to your applications.
The preferred alternative to SMS is to utilize smartphone apps that generate time-based, one-time passcodes (often referred to as TOTP). Or even better, deliver push notifications to initiate a more user-friendly, more secure approve or deny style of authentication. Because this all runs in software on a device, we can gather a little data to help you answer important questions about the authentication process, above and beyond just checking the 2FA code is valid. Still, even when using a software-only solution for 2FA, there are other risks involved:
- How was the 2FA installed?
- Was the app installed recently?
- How many times has the user used this app on this device to login?
- Has the user explicitly said they trust this device?
- Where is the app running? On a desktop or a mobile device?
Make Better Authentication Decisions
We spoke to many of our customers about these concerns and with businesses that were very risk averse, typically online banking or digital currency services (eg: bitcoin, ethereum). It became apparent that both developers and enterprise organizations are keen to know as much as possible about where 2FA codes come from (SMS or app-based) and what sort of trust they can build in the device used to authenticate. This, coupled with the fact that SMS-based 2FA was becoming less favored, resulted in new and useful data points being added to our 2FA API to help customers make better authentication decisions. Consider these potential use cases:
- Prohibit SMS-based 2FA for high-risk users or transactions (accounts over a predetermined amount.)
- Assess risk based on location by comparing IP address and region of the initial Authy app registration with the IP and region currently being used for authentication.
- Disallow use of 2FA codes from desktop apps when the user is accessing your web interface. (Inversely only allow codes from desktop apps when user is accessing a mobile application).
- Immediately validate a 2FA code — and remember the ID of the device — at the time of enablement. Future authentications for this user will only be allowed from the same device.
- Introduce a 48-hour waiting period before trusting Authy apps installed via SMS while you notify the user of the newly installed app.
Improving 2FA with Device Data
When a request is made to initiate a two-factor authentication, the Twilio Authy API immediately determines if the user has the Authy 2FA app installed. If so, it sends a push notification to the users Authy apps to prompt for a software generated token, and does not send the SMS. This is both more secure and less costly. When you verify codes in your application, the response now includes information about where the code comes from. And because our API causes a different code to be generated on each user device, it allows us to know exactly which one is making the request.
The image below compares the information revealed when the API verifies different 2FA codes. The first shows a token verified by SMS. The second example shows a token verified from the Authy Desktop on macOS, installed a few years ago from a US-based IP, authenticated via another Authy app (via a push authentication). The final example shows a token from an iOS instance of Authy, installed via SMS from a China IP in the previous 24 hours.
By evaluating the information about where an authentication request is generated, your 2FA offering is even stronger. In fact, if you are implementing push notifications, the latest in 2FA authentication features, this data is included the callback to your application. So whether you provide SMS, one-time passcode, or push-based authentication, you can now evaluate the risk of the device being used and protect your application, your business, and your users with smarter security solutions.
To learn more about how the API works:
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.