What’s next after SMS one-time passwords?

NIST has gotten a lot of attention lately because they pointed out that SMS is less secure than many people think, and if you’re trying to shore up passwords with a second login method, you should probably consider using something that’s more secure. This type of “shoring up” of passwords is called two factor authentication, or 2FA for short.

People use 2FA for lots of stuff, from protecting classified information to protecting your Tweets. In many cases, it’s used to put a band-aid on passwords, and there are actually better options nowadays, but we’ll get to that in a bit.

SMS is one of the most popular 2FA approaches out there, and for good reason. It works for anyone with a cell phone, it’s pretty easy to use, it’s cost effective, and it’s not hard for developers to integrate into their products. To a casual observer, it also seems to mean that you need to have your phone in order to get into your account. That’s often true, but it’s not always, which is the root of the problem. The use of SMS in 2FA is to use “something you have” (your phone) as proof, but the section below will show you how that may not be true with SMS one-time passwords.

But wait a minute, who is NIST to tell you what to do? Well, NIST makes security recommendations that apply to the US government. They can’t (and probably don’t want to) tell Twitter or your bank what to do. That said, NIST is very knowledgeable about security and very influential, so you’ll see that their recommendations have a way of being adopted by the Internet. For instance, NIST ran the competition to choose and standardize the “Advanced Encryption Standard” (AES), which you use every day whether you know it or not. The SMS guidance is still in draft form, but is already having an effect on how companies and the government address 2FA.

How SMS gets attacked

Changing away from SMS as a second factor will be a massive amount of work for everyone involved, including end users. So what are the vulnerabilities with SMS that prompted NIST to make such a serious recommendation?

First off, SMS is used by a wide variety of organizations: From small, zero-impact apps to large critical government agencies. Security 101 says that you should analyze the risks and vulnerabilities in your login system, but it’s extremely difficult for anyone to know what vulnerabilities they are exposed to with SMS. Put simply, SMS isn’t one thing. Every user, every phone company, every SMS cloud middleware provider, and every phone has a different set of vulnerabilities.

For instance, an attacker with no technical skills can target a specific individual, call up the phone company, and take over their phone number to break into their account. All they need is some smooth talking and a little bit of luck. This situation is clearly incompatible with the need for moderate-to-high impact systems to have multi-factor authentication.

Indeed, coupling SMS and passwords does not necessarily get you multi-factor authentication. The usual way of thinking about 2FA is that it includes two different types of proof. Typically, it’s something you know (e.g. a password) coupled with something you have (a phone) or a biometric. Despite the appearance to a casual observer, an SMS one-time password (OTP) does not demonstrate possession of a physical device by the intended user. Instead:

  • It may be relayed through various third parties: SMS middleware, telephone companies, mobile OS companies, VOIP companies, and app authors.
  • It may then be relayed to several cloud-connected devices (including the computer the user is logging in on), and read by various apps on the device.
  • The phone number that the user registered in the past might now be reused by a new person or taken over by an attacker.
  • The IP or wireless networks delivering the OTP may have flaws that allow for passive or active interception.

We outline each of these concerns below.

Ideal 2FA Scenario: The user enters their password and receives a one-time password (OTP) on their phone from the mobile carrier. They type their OTP into the web site, to prove control of their phone:


Unexpected Intermediaries: You might think that OTPs get sent straight to the user, but in fact, just because you have the OTP doesn’t mean you have the phone. In modern SMS infrastructure, many other actors receive the OTP, potentially defeating the intention for 2FA to include “something you have”.

  • VOIP Service: Many phone numbers are now not tied to a phone at all. For instance, Google Voice is a way to create a phone number and receive text messages in a browser.
  • SMS Middleware: Many web sites go through an intermediary to relay SMS from web APIs to the mobile infrastructure. The reason? It’s actually pretty hard to send SMSs across the different operators and the different nations your users might live in.
  • Cloud / app services: Systems like iCloud and PushBullet relay messages from the user’s mobile, via cloud services, to their computer. This is extremely convenient for the user, but does not necessarily meet the goals of 2FA for the organizations.

These intermediaries are pictured in the diagram below:


Potential Vulnerabilities: Any 2FA system can have vulnerabilities. (Even hardware-backed tokens have been hacked at scale.) But one of the goals of a “something you have” factor is to make the bad guys actually steal your hardware. With SMS, the OTP goes through many systems, increasing its attack surface:

  • State Actors: With or without the cooperation of mobile operators, state actors can intercept OTPs in order to take over accounts or read messages. This was on display recently when the secure message app Telegram was compromised by (reportedly) state-sponsored hackers that apparently operated in collaboration with the telco.
  • Redirected Number: An attacker with no technical skills can target a specific individual, call up the phone company, and take over their SMS to break into their account. All they need is some smooth talking and a little bit of luck.
  • Network Attacks: Much of the routing infrastructure that SMS relies on was not designed with modern strong security approaches, and as a result, security flaws have been discovered that impact most users.
  • Wireless attacks: There have been a number of attacks on mobile wireless protocols, allowing attackers to intercept OTPs on their way to your phone.
  • Malicious Apps: On some mobile platforms, any app with permissions can read SMS texts, including OTPs. These can then be relayed to other parties.

These vulnerabilities are depicted in the diagram below:


The following combined diagram depicts the reality of SMS-based OTPs. Organizations that use SMS to protect their assets have very little visibility into where their OTPs go after they are sent:


Predicting the future

So what does it mean for NIST to deprecate SMS for 2FA? Here’s what we think will happen over the next few years:

You’ll see more SMS attacks, both targeted and at large scales. NIST is making this recommendation because they believe that SMS is getting attacked at large scales and the weaknesses in SMS (which have always been there) are becoming a more serious liability.

Companies offering SMS services will shore up SMS to address some of the security issues. For instance, NIST is recommending that you should detect when the SMS number is tied to a VOIP account instead of a cell phone.

The US government, and organizations that do business with it, will start to shift away from SMS for security. After all, it’s the government that NIST guidance really applies to. This has a trickle-down effect to state and local governments and to government contractors, who are often bound to follow the same security protocols as the government.

Regulated industries like banks will shift away from using SMS. As the vulnerabilities become more widespread, and if the “shoring up” of SMS isn’t good enough, the risks will be too high.

Transitioning from SMS to stronger two-factor auth

As you might guess, we agree with NIST’s draft guidance for federal agencies. We believe that organizations should utilize 2FA and that at higher levels of security, SMS should be replaced with something more secure. That said, we recognize that SMS is still appropriate for many systems, and transitioning from one to the other can often be a daunting task. Also, as stated before, SMS has big usability and ubiquity advantages which makes it hard to ignore.

To help with both using SMS intelligently and preparing to transition away from it, we’ve been working on a solution that uses SMS for onboarding and 2FA with a built-in transition path to a cryptographically strong second factor.

First, Tozny uses SMS one-time passwords to make account creation or 2FA set-up dead simple. If you have an app for iOS or Android, you can try this out right now through our software development kits. Basically this means that any programmer can add SMS one-time passwords to their apps really easily. Here’s a video for example:

Next, when you’re ready for more security, users can be seamlessly transitioned to stronger authentication. Embedding Tozny into your app allows users to log in by pushing a button. This is backed by strong cryptography: a private key on the user’s phone and a challenge-response protocol. It uses the hardware-backed key storage on your phone. One-click crypto login is illustrated by the following video:

So in summary, you can:

  • Use Tozny authentication for SMS onboarding and 2FA today,
  • Use the same solution for cryptographic 2FA as you transition away from SMS, and
  • When ready, ditch passwords altogether in favor of an easier and more secure solution.

Note: We work with NIST on the NSTIC project but we do not represent NIST in any form. The views expressed in this post are ours, and ours alone.