Welcome back to the two factor authentication (2FA) series!

If you haven’t already, check out the first article in the series that explains what 2FA is and why you really should enable it on your accounts (yes, even if you have a strong, unique password).

In this article, we are going to talk all about how the SMS implementation of 2FA works. We’ll use the abbreviation SMS 2FA as we cover the technical details, highlight security vulnerabilities, and discuss usability tradeoffs.

A quick reminder that the authentication factors associated with 2FA are the knowledge factor (something you know) and the possession factor (something you have).

Before we jump into the juicy details, let’s clear up one thing right off the bat. Even though SMS 2FA is extremely prevalent among service providers, it has many well known vulnerabilities that prevent it from satisfying the intent of a possession factor of authentication. In other words, you cannot rely on SMS to actually prove “something you have” to a service provider. In fact, the National Institute of Standards and Technology (NIST) has deprecated the use of SMS for 2FA in US government systems as of June 2017. This article should give you a better understanding why that was a prudent decision and what to do about it.

Initial registration

Let’s start by taking a look at the typical SMS 2FA registration process.

I will define “service provider” to mean the website service provider (e.g. Google, Facebook, Twitter, etc) and “phone company” to mean the user’s cell phone service provider (e.g. ATT, Verizon, etc).

After selecting SMS 2FA from the security settings, the registration process is quite straightforward. First, the user (let’s call her Alice) enters her phone number. Next, the service provider generates a unique one time password (OTP), for example a 6 digit code, with the goal of sending it to Alice’s phone. To do this, the service provider sends an SMS containing the OTP to the phone company, who then forwards it to the device registered to the phone number that Alice entered. Ideally, Alice receives the text message containing the OTP and types it into her browser. The service provider verifies that the OTP Alice entered matches the OTP it originally generated for her registration session and successfully enables SMS 2FA on her account.

You likely caught all of that tentative hand wavy language in there, right? I promise we’ll talk about the security vulnerabilities that force me to qualify most steps in that workflow, but first let’s take a look at the authentication process when Alice tries to log into her account.

Authentication during login

Unsurprisingly, the SMS 2FA authentication process looks almost identical, except that Alice does not need to enter her phone number since that was already saved upon successful registration.

Assuming the authentication process works as intended, SMS 2FA is pretty user friendly for anyone who has ever received a text message on their phone. That group certainly includes a lot of people! However, let’s take a closer look at each step of this workflow to understand the security vulnerabilities with SMS 2FA.

In the following diagram, I put a red box around the main source of vulnerabilities with SMS 2FA. Yup, the red box fully contains the phone companies.

What if I cannot access my phone?

So, what happens if Alice loses, breaks, or otherwise cannot access her phone? Luckily, she doesn’t have to worry about getting permanently locked out of her account.

Alice can easily go to the Verizon or ATT store, buy a new phone, and set it up to her existing phone number. Just as her friends can still call and text her same phone number, SMS 2FA will continue working without any modifications.

Wait a minute. 2FA combines the knowledge factor (something you know) and the possession factor (something you have). The trusted device for Alice’s possession factor was her phone, which she lost. If the trusted device really were “something she has”, then shouldn’t Alice lose access to her account when she loses her phone? Or, at least she should have to resort to using a 2FA recovery code to access her account, right?

Indeed. Therein lies the rub.

People can receive text messages in dozens of ways that don’t involve a phone. For example, you might route your text messages to your tablet or email address. Or, you could access your text messages online via your cell phone provider’s website using only a password (something you know). Or, maybe you’re using Google Voice or another VoIP service that also works completely online via a website or app and can be accessed from any device.

One time passwords (OTPs) sent via SMS do not prove physical possession of a trusted device. Therefore, SMS does not satisfy the intent of a possession authentication factor.

Clever readers are realizing that if Alice could walk into a store and buy a new phone to solve her “lost phone” problem, then that likely means that someone pretending to be Alice could do the exact same thing.

Finally, we can start talking about the security vulnerabilities of SMS 2FA.

People are always the weakest link

Instead of hackers trying to steal your physical phone, they can use remote attacks to steal your phone number itself. How does that work, exactly? By tricking people!

Whether its SIM swapping, SIM hijacking, SIM cloning, or number porting, hackers can use social engineering to convince someone at your cell phone provider that they are you and to activate a new SIM card associated with your phone number. Once this happens, the hacker will get all of your SMS and phone calls on their phone and your phone will just stop working.

There are already many excellent resources out there detailing the social engineering attacks on SMS 2FA. Wired has an excellent article from June 2016 titled “So, hey. You should stop using texts for 2FA” in which they highlight how hackers hijacked Black Lives Matter activist DeRay McKesson’s Twitter account after convincing Verizon to change the SIM card on his account to point to their phone instead.

By calling @verizon and successfully changing my phone's SIM, the hacker bypassed two-factor verification which I have on all accounts.

— deray (@deray) June 10, 2016

In mid-2016, Lorrie Cranor, then Chief Technologist of the FTC, also had her phone's SIM card hijacked using social engineering. She highlighted that the New York Department of Consumer Protection has a formal warning about this type of scam on their website.

In late 2016, Forbes reported that hackers had again used social engineering techniques to take control of a victim’s phone and was able to defeat SMS 2FA to steal millions of dollars worth of bitcoin. The New York Times reported in August 2017 that attacks to control phone numbers continue to increase as hackers try to subvert SMS 2FA on cryptocurrency accounts.

Some used to argue that even though SMS 2FA had social engineering vulnerabilities, the attack was difficult for hackers to pull off because they had to target specific people and gather enough information to convince the phone company that they were the victim. This antiquated argument becomes less persuasive with each passing day.

It is true that phone companies are supposed to authenticate your identity before making changes to your account, but that usually involves asking questions such as your name, address, Social Security Number, etc. Basically, exactly the type of information that is now widely available as of September 2017 thanks to Equifax.

Just earlier this month in Feb 2018, T-Mobile sent a mass text to all of its customers warning of an “industry wide” phone hijacking scam in which hackers would convince phone carriers to port numbers to a different carrier, taking control of the number in the process. T-Mobile even has a dedicated page on their website discussing the risk of number porting. Clearly, not such a small problem.

Even if the phone companies were somehow able to address the problems of social engineering, there will always the insider threat to consider. John McAfee, the creator of McAfee AntiVirus, had his Twitter account hijacked and speculated that someone at ATT might have been bribed by hackers to switch his number to point to a different phone. While he has no evidence to back up that claim, the technical risk will always exist because SMS 2FA completely relies upon the phone companies to “get it right” and, clearly, they often don’t even come close.

Vulnerable to SS7 attacks on the phone network

We’ve covered vulnerabilities at the phone company, but we’re not done talking about the risks in that red box featuring the phone company quite yet. Now, let's talk about technical vulnerabilities with SMS.

There is a well-known vulnerability in the phone network that does not rely on social engineering at all. Signal System 7 (SS7) is a series of protocols that handles routing phone calls and text messages throughout the global phone network. It was created back in 1975 and, shockingly, is still at the core of the global phone networks today, over 40 years later. MotherBoard highlights that “security and authentication were never really built into the SS7 network from the start, and much of the network remains inherently vulnerable to abuse”.

These vulnerabilities give hackers a technical method of routing your SMS messages directly to their phones without talking to your phone company at all.

Though known about and discussed for years, 2016 was a popular year for featuring SS7 vulnerabilities in the media.

Positive Technologies demonstrated how to use SS7 vulnerabilities to hijack WhatsApp accounts and highlighted that the “SS7 network can be compromised by attackers... It’s a known fact that one-time codes via SMS are insecure, because mobile communication is insecure.”

Forbes also wrote about how you could pay an Israeli company to spy on any phone in the world and remotely record text messages.

Many argued in the past that exploiting SS7 was difficult and expensive because the network was originally restricted to the large phone network operators, of which there were only a handful. MotherBoard points out that isn’t really the case anymore:

...in recent years, the definition of a network operator has changed—to the point where, today… practically anyone can become an operator. Upstart cellular carriers, VoIP providers, and third-party SMS services that piggyback on the global cellular network all have access to SS7 now, and they can share that access with others.

In May 2017, The Hacker News reported that “cyber criminals exploited SS7 flaws to intercept two-factor authentication codes (one-time passcode, or OTP) sent to online banking customers and drained their bank accounts.” MotherBoard also reported this attack and even used the opportunity to responsibly invalidate an article they wrote just 5 months prior titled “You're Probably Fine with SMS-Based Two-Factor Authentication”. Yea. Not so much anymore.

An article on Security Intelligence sums up SS7 succinctly:

...experts have known for the last 30 years that SS7, the switching protocol used by over 800 global telecoms, is insecure... The most important takeaway is to understand that the telephone network that your phone connects to is not secure and probably never will be.

The phone company can always read your SMS messages anyways

Even if the vulnerabilities in SS7 were addressed somehow and the phone network was secure, SMS is still a poor solution for 2FA because SMS messages traveling through the phone network are not end-to-end encrypted.

Communication between your phone and the cell phone tower does have several security measures in place, but without end-to-end encryption the phone company can still read the contents of all of your SMS messages. Yes, this includes the one time password (OTP) that is intended to "prove" that you have physical possession of your phone.

Some readers may be aware that many communication apps do support end-to-end encryption. For example, millions of people use Signal, a well known and respected privacy concsious communication app, to send end-to-end encrypted messages. WhatsApp and Facebook Messenger also implemented the Signal protocol support end-to-end encryption for their 2.4 billion users. Apple's iMessage also supports end-to-end encryption. However, none of those apps use SMS as the underlying technology. They all require a client application (a mobile or desktop app) and a data connection to work.

Vulnerable to phishing and MITM attacks

The diagram above shows that even if it works as intended, users of SMS 2FA are still vulnerable to phishing attacks.

In this scenario, Alice thinks that she is on a legitimate site, so she tries to log in with her password. In the background, the hackers running the phishing site can easily use the password Alice provides to log into the real site. The service provider will verify Alice’s password, generate an OTP, and send it to Alice via SMS. Again, Alice thinks she is on the legitimate site and knows that she has SMS 2FA enabled, so she happily enters the OTP into the phishing site. As soon as she does, the hackers can use that valid OTP to successfully log into Alice’s account on the real site. Game over.

SMS 2FA is similarly vulnerable to Man in the Middle (MITM) attacks. The phishing attack relies on fake websites that look real to trick Alice. If Alice falls victim to a MITM attack, then she is actually connected to the real website, but is connected on an insecure HTTP connection. This allows hackers to read all of the network web traffic, including the OTP that Alice manually entered into her browser.

Remember, HTTPS helps prevent MITM attacks; you should go install HTTPS Everywhere to help with this.

Vulnerable to malware / keyloggers

In the introduction article to this series, we discussed how many 2FA methods are vulnerable to malware and keyloggers. SMS 2FA is one of those methods.

The common architecture of SMS 2FA does not use out of band (OOB) verification.

In the diagram above, the connection between Alice's computer and the service provider (steps 1 and 4) is the "primary channel". The communication between the service provider and Alice's phone (steps 2 and 3) is the "secondary channel". Notice that the password (something Alice knows) and the OTP (something Alice "has") are both sent to the service provider via the primary channel. This means that the hacker only needs to compromise the primary channel in order to gain access to the account. This could be done via malware on Alice's computer.

If the architecture were changed such that Alice was required to echo the OTP back to the service provider via the secondary channel (e.g. SMS through the phone company), then that would count as OOB. This architecture would fare better in terms of malware on Alice's computer, but malware can infect phones too. If Alice had malware on her phone that could read her text messages, then OOB SMS 2FA would still pose a risk.

So, what should we do about SMS 2FA?

Even given all of the vulnerabilities that we’ve discussed, SMS 2FA still remains unquestionably the most popular 2FA implementation.

There are many reasons for this, but the most straight forward boils down to usability. Most people already have a phone that can receive text messages and they can easily type 6 digits into a browser.

Some make the argument that SMS 2FA shouldn’t be deprecated because it is better than nothing. Indeed, I strongly agree that SMS 2FA is better than nothing, but that is a straw man argument. The decision isn’t between SMS 2FA and nothing. It is between SMS 2FA and at least three other main stream 2FA methods: time-based one-time passwords (TOTP), Push notification, and U2F. Compared to the alternatives, SMS 2FA is unquestionably the weakest and NIST’s decision to deprecate it is sound guidance for most service providers so that users are not relying on insecure legacy solutions.

If you are an end-user, here is what I recommend. First, use the incredibly handy 2fa.directory to lookup whether the service offers any 2FA. If they don’t, send them a grumpy tweet and pressure them to add 2FA support! If the service only offers SMS 2FA, then enable it! Even though it is the weakest form of 2FA, it certainly is better than nothing! A grumpy tweet asking for better options is likely still appropriate. Your call. If the service offers more secure methods of 2FA, then avoid relying on SMS. There are more secure options that are still very convenient to use. We’ll discuss all of those other 2FA methods throughout the rest of this series. Stay tuned!

If you are a service provider actually building software, then your decision is only slightly more complicated. As NIST recommends, you should “determine the level of acceptable risk for their system(s) and associated data” and if you choose to implement SMS 2FA, then you need to “assess, understand, and accept the risks associated with that RESTRICTED authenticator and acknowledge that risk will likely increase over time”.

It isn’t difficult to read between the lines and understand that NIST is saying SMS 2FA has too many vulnerabilities to justify, especially in new projects. It doesn’t anticipate SMS 2FA getting “fixed” and, all things equal, you really shouldn’t support SMS 2FA because it is not secure.

Of course, there are scenarios in which all things are not equal. Many services target users all over the world, where people might not have the ability to use other forms of 2FA. For example, if a sizeable portion of your user base does not have smartphones, then they can’t use Push or TOTP. If they cannot afford to purchase a few physical devices, then U2F isn’t an option either. In this case, certainly SMS 2FA is better than the alternative, which is no 2FA!

The main problem, though, is that your user base is not uniform. You will certainly have some users who do have a smartphone and/or can purchase some inexpensive U2F tokens. It is common for services to offer multiple 2FA solutions for exactly this reason. Unfortunately, the decision of which method to use is often left entirely up to an uninformed user base. Duo, a leading provider of two factor authentication (2FA) solutions, found that only ~28% of people in the US use 2FA and only ~56% even knew what 2FA was before their survey. Pew Research Center conducted a cybersecurity quiz in which only 18% of users could correctly identify multi factor authentication (MFA).

Many users who can utilize a more secure method of 2FA will likely just choose to use SMS simply because it is familiar and does not require the additional step of downloading an application or purchasing another device. Obviously, most users will not have read something like this series of articles to educate themselves about the differences between 2FA implementations.

Users might know that they should enable 2FA and think that they are getting the same level of security from each option presented. If they select SMS 2FA, then they are unknowingly opting into the least secure 2FA method available.

As a service provider, it is your responsibility to educate your users about the basic security tradeoffs between the offered 2FA options. Then, users can make a more informed decision and, hopefully, understand the risk tradeoffs they are making by choosing SMS 2FA. In fact, NIST specifically requires service providers to “provide meaningful notice to subscribers regarding the security risks of the RESTRICTED authenticator and availability of alternative(s) that are not RESTRICTED.” In other words, if you do offer SMS 2FA, you need to tell users that it is insecure and highlight available options which are more secure.

Of course, if your service targets users who do have smartphones, then I suggest just avoiding SMS 2FA entirely and supporting TOTP and/or Push instead. Users will get better security with fewer decisions to make.

Wrap up

In short, SMS doesn’t actually prove “something you have”, so don’t rely on it for 2FA unless you absolutely must. Other 2FA methods are far more secure and some are even more convenient to use! Push doesn’t require you to manually type an OTP into your browser and both TOTP and U2F do not require a network connection at all, which is great for traveling. We’ll cover all of the details about those 2FA methods throughout the rest of this series. Join the email list below to make sure that you don’t miss the next article where we discuss TOTP 2FA!

One last parting reminder. If you are into cryptocurrency, you should absolutely favor more secure 2FA methods over SMS 2FA anywhere you can. You don’t want to end up losing millions of dollars if hackers target you and break into your online wallet. You do have millions of dollars by now, right?

Edit: Check out the next article in this 2FA series: TOTP: (way) more secure than SMS, but more annoying than Push.

Thanks to Jordan Fischer, Geoff Kimble, and Kristie Butler for reading drafts of this.