Hang up the Phone: MFA’s Insecure Reliance on SMS

It’s hard enough to get people to use multi-factor authentication (MFA)—you know, something you know, you have and you are. Most websites, email accounts and other devices are secured (if at all) with a simple user ID (or email address) and password—and frequently with insecure, reusable, stored and retransmitted credentials at that. Having someone authenticate additionally via a text message is already a miracle.

But, as we have long known, MFA is not truly secure unless the factors themselves are secure and independent of each other. If the credentials are all stored together, then it’s really just one factor, right? If a physical token needed for authentication is persistently plugged into the device, then it’s not a token, it’s a feature of the device. It provides some assurance that the communication came from the authenticated device, but not that the owner of the token inserted the token in the device.

For reasons of ubiquity, cost and convenience, we have used cellphones in general and SMS messages in particular as a factor and channel of authentication in MFA systems. Since we always carry our smartphones with us, we can log in to a website with a set of credentials, receive an SMS message with the third credential (an authentication code) and even have our phones automatically detect and retransmit that credential to authenticate the user and the device. Easy peasy lemon squeezy.
Except that it doesn’t work—or, more accurately, it doesn’t work well.

The Weakest Link

The problem with MFA and authentication by cellphone is that it requires the device itself to be secure and authenticated. It has to be a secure device with secure authentication on a secure and authenticated network, without data leakage or credential leakage and with a device and network authentication that cannot be altered and spoofed. While the public switched telephone network (PSTN)  is secure against some attacks, there are a wide variety of attacks on both the network and devices on the networks that make the network unsuitable for strong authentication.

The most common problem is that of SIM swapping—disassociating the customers’ SIM chip from the physical device. It’s done with a combination of technology, bribery and social engineering, and has been successfully used to steal tens of millions of dollars in cryptocurrency from brokers, traders or others, as well as other frauds. Mails, texts, updates and other communications meant for the phone’s owner are redirected to a spoofed telephone doppelganger, which appears to the network as the true device. SMS “confirmation” texts are sent to the threat actor and, voilà! The money, credentials or whatever is just dust in the wind.

A recent article by Alex Weinert, director of identity security at Microsoft illustrates this point. Weinert pointed out that MFA SMS confirmations, which are sent over the PSTN in clear text, are vulnerable not only to SIM-swapping attacks but also to things such as software-defined radio interceptions, FEMTOcell intercepts or exploiting the phone company’s SS7 vulnerabilities to permit the interception of the SMS confirmations. Moreover, if a hacker obtains other user credentials, they may be able to see the contents of SMS messages by logging into the user’s cell phone account online and simply reading the messages—or even getting the cell phone company to do it for them. SMS messages are easy to transmit, short and to the point, but they are not particularly secure.

Once you add an insecure authenticator to another insecure authenticator, you have insecure MFA. Sure, it’s technically “multi-factor,” but it doesn’t do what you want it to do: authenticate the user.

Microsoft’s Weinert recommended the use of Microsoft’s Authenticator, although there is a wide variety of token-based or software-based authentication, including Google’s Duo device. In choosing an authentication scheme, you should consider characteristics, factors and channels. The best authentication takes into account the different characteristics of the authenticator (knowledge, possession, biometric) and uses a combination of these characteristics. If the authenticator is, for example, something you know, then it should be something you uniquely know, not something that can be easily looked up (Mom’s maiden name) or guessed (favorite sports team). It should also not be something that can be brute-forced (password – Passw0rd) or something that is used on other sites, right? For the “something you are” it needs to be reasonably unique (DNA wouldn’t work for me or my identical twin), easy to measure, difficult to spoof or represent, and created and stored with privacy in mind. And for the “something you have” it has to be something that you have, have with you, have (almost) all the time and that is unique and cannot be spoofed.

That’s just for characteristics. As for “factors” you need to ensure that your authentication scheme relies on things with disparate characteristics and that these factors are independent, stored independently and reasonably strong and secure. Finally, you have to consider the channel through which the credential is created or transmitted. If all of the factors are transmitted through the same device or over the same means of communication, then a compromise of the device or channel of communications may compromise more than one of the authentication factors.

MFA, SSN, OMG

An overlooked issue in any authentication scheme is also to understand what it is I am authenticating. Am I authenticating identity? Authorization? Permission? To get a college transcript (from the Pliocene age) I had to provide the college with a “student ID.” But we didn’t use student IDs,  just Social Security numbers. “Oh no,” the registrar complained, “we can’t use those, for security and privacy reasons. We need to get you a student ID.” How do we do that? “Just give me your Social Security number …” To get a “secure” driver’s license, I need to present an insecure birth certificate. I can then use the driver’s license to get a passport. Now I’ve linked a name, an address, an SSN and a biometric (picture) to an identity. Kewl. It’s just that the identity is not necessarily me. When I create an account and confirm it with an SMS, the phone number used for confirmation is one that was entered at the time of account creation. Access to the account provides access to the authenticator.

As identity and authority become critical for applications, funds transfers, medical treatment and a host of other purposes, we need better and more secure methods of authentication. A text message won’t cut it. CUL8R.

Featured eBook
The Dangers of Open Source Software and Best Practices for Securing Code

The Dangers of Open Source Software and Best Practices for Securing Code

More and more organizations are incorporating open source software into their development pipelines. After all, embracing open source products such as operating systems, code libraries, software and applications can reduce costs, introduce additional flexibility and help to accelerate delivery. Yet, open source software can introduce additional concerns into the development process—namely, security. Unlike commercial, or … Read More