En Garde

MFA, two-factor, 2fa, multi-factor authentication…

We’ve heard it called by many names, some of them not entirely appropriate for polite conversation. It was hard enough to remember our passwords, but now we must fumble through apps, passcodes, push notifications, and text messages to try to get into the accounts we need to do our work. MFA (my term of choice for the rest of this article) is undeniably another layer of tech inconvenience to add to the ever-growing pile. Still, it is admittedly much less inconvenient than having your bank account emptied by a lucky-strike script-kiddie in Belarus (a script kiddie is a type of hacker who uses pre-configured hacking tools and doesn’t know all that much about real hacking). A study presented by a panel from Brigham Young University at a 2019 Usenix symposium found that, though the initial setup for MFA could be frustrating, users got much more adept at performing MFA over time and even expressed interest in implementing these methods for some of their other sensitive online accounts. The bottom line is that we can adapt to each new layer of security necessary in an ever more connected world, despite the initial inconvenience.

But how much do we have to adapt? How inconvenient does MFA have to be? This next question is more nuanced because of the multiple possibilities for MFA. The National Institute of Standards and Technology (NIST) lists many authentication methods that can be mixed and matched to achieve certain levels of authentication security. These range from memorized secrets, look-up secrets, and out-of-band verifiers to multi-factor cryptographic software and device authenticators. These may seem outlandish, but complex terminology is the bread-and-butter of government regulatory documents. Fortunately, most of these have readily available translations into a more accessible vocabulary. For example, memorized secrets correspond directly to passwords. However, this article will explore the less straightforward world of out-of-band and one-time password (OTP) devices. We will introduce a friendly competition, a duel of sorts, between these MFA methods: phone SMS and the Microsoft Authenticator app.

The Dual-Factor Duel

In the right corner, we have phone SMS, one of the most common MFA methods. Many of us have used it before:

Put in your username.
Enter your password.
Wait for a one-time code to be sent to your phone; voila, you’re in.

One login, one code, through the tried-and-true text message.

In the left corner, we have the Microsoft Authenticator app, a proprietary piece of software that supports several different methods of MFA. It can either send a push notification to your phone, provide you with a one-time code (like phone SMS), or send a notification that requires the user to enter a number and approve the sign-in.

While phone SMS operates solely as a single-factor out-of-band device, the Microsoft Authenticator app’s features allow it to function as a multi-factor or single-factor out-of-band device or a single-factor OTP device. To understand these phrases, as crunchy with tech jargon as they are, we need to look at NIST’s standards for authentication methods.

NIST takes a maximalist approach to documentation. They have four separate publications covering various aspects of digital identity, helpfully labeled SP 800-63-3, 800-63A, 800-63B, and 800-63C. Our special interest is 800-63B, which provides definitions and recommendations for authentication methods. Zooming in even further, we are concerned with the three types of authentication our contenders are capable of single-factor out-of-band, single-factor OTP, and multi-factor out-of-band.

NIST defines out-of-band devices as “physical device that is uniquely addressable and can communicate securely with the verifier,” which means that it provides a second communication channel that can be used to verify the login. Text messages are a straightforward example of this. The Microsoft Authenticator accomplishes this by sending a notification to the phone with the app installed, which can be approved to finish the sign-in. The app can also function as a single-factor OTP device like the single-factor out-of-band device. It calculates a time-sensitive code entered when one logs in using a secret key.

Multi-factor out-of-band devices are different animals, like a griffin or a jackalope. In other words, Microsoft made them up. Though Microsoft references the term in their official documentation, NIST 800-63B has no category for multi-factor out-of-band authenticators. Microsoft claims to achieve passwordless authentication using their app by requiring users to use their phone’s PIN or biometrics to access the Authenticator app to approve any out-of-band notifications. However, even disregarding the illegitimacy of the term, Microsoft cannot guarantee that a user’s PIN complies with NIST’s guidelines for passwords, which require at least eight characters for a password that is not randomly generated.

To review, our text-message titan beats hackers back with NIST’s single-factor out-of-band authentication power, while the Authenticator app’s multi-factor alliance harnesses not only single-factor out-of-band but also single-factor OTP abilities with the occasional unicorn glimpse of a “multi-factor out-of-band” device.

NIST Riposte

So, which is more secure? In 2016, the battle between our two contenders would have been brief and bloodless. The 2016 revision of NIST’s 800-63B document designated phone SMS authentication as “deprecated,” which would have been a death knell to its use as an authenticator. However, by the following year, NIST had revised its opinion and downgraded the original harshness of its sentence to label SMS as “restricted” instead. This means that the use of phone SMS is a risk that the organization must recognize and accept.

NIST originally deprecated and later restricted phone SMS as an out-of-band authenticator because of several fundamental security flaws in its architecture and implementation. These flaws expose one-time codes sent over the phone network to interception, decryption, and theft. There are three main methods, two of which exploit the architecture of phone networks themselves and require some technical expertise, while the third merely requires a little fast talking.

The first method of intercepting SMS messages within the existing phone architecture is most prevalent where the system still uses legacy 2G GSM networks, which do not support strong encryption and can easily be fooled into forwarding messages to a rogue phone tower. An eavesdropper, provided they knew the geographical location of their victim, could intercept an individual’s one-time codes, decrypt them and hack into the respective account. Though it may sound like a tall order to set up a phone tower after geolocating a would-be victim, some methods exploit the GSM protocols' weaknesses, making geolocating users easier.

Though 3G LTE systems are less vulnerable to this kind of attack, there are ways in which hackers can cause smartphones to downgrade from 3G to using 2G authentication. Additionally, even 3G systems, though they implement stronger encryption, also exchange information in plain text, exposing phones using LTE networks to geolocation tracking and some denial of service attacks.

The second type of vulnerability in phone SMS authenticators concerns the Signaling System 7 (SS7) protocol CAMEL. This protocol has vulnerabilities that allow any attacker with access to a node in the SS7 network to overwrite the address of a phone subscriber and intercept all phone or text traffic to that subscriber. Though phone companies are doing their best to monitor access to SS7 nodes, access can be purchased on the dark web or legitimately from the phone companies themselves.

The ease with which man-in-the-middle attacks (in which the hacker intercepts all of a victim's messages and calls) can be performed using SS7 nodes is likely what prompted NIST to restrict the use of SMS for authentication in the first place. One of the few downsides (for the hackers, at least) to this method of SMS interception is that purchasing an SS7 node, whether from the dark web or elsewhere, requires a significant amount of capital. Therefore, SS7 attacks tend to be less targeted at the everyday user and more towards internationally motivated targets. However, security-by-obscurity (a fancy way of saying the hackers have bigger fish to fry) is not a valid defense mechanism in the long run.

Modern LTE networks have moved away from SS7 to use the newer Diameter protocol, which supports the same level of encryption as the Internet. However, many phone operators misconfigure this protocol and fail to take advantage of its security features, often leaving calls and texts over LTE networks just as insecure as its predecessor.

The final method weapon in the SMS interceptor’s arsenal is SIM swapping. This old-school fraud attack consists of more confidence than coding: the perpetrator simply calls the phone company and asks for a certain account to be switched over to a new SIM card, one in the perpetrator’s possession. Because phone companies do not properly authenticate the request, it is often laughably easier for hackers to get away with this trick, thereby gaining effortless access to all the one-time codes sent to a certain user. One study found that even when potential fraudsters failed multiple authentication challenges, as long as they got one right, they could still authorize a SIM swap.

Though the SIM swap is the low-hanging fruit of the phone exploit world, it is time-consuming and hard to do en masse. Social engineering cannot (at least not yet) be scripted with Python, though AI may change that. Notwithstanding, several hacking groups have taken to bribing customer service employees or using RDP to perform the SIM swaps themselves.

SIM swapping, while the easiest phone SMS vulnerability to exploit, is also one of the easiest to stop. After experiencing debilitating levels of bank fraud via SIM swap attacks, multiple countries in Africa pioneered a method of mitigating the risk. Whenever an individual tries to authenticate to the bank using their phone, the bank can contact the phone company using an API to ascertain whether the mobile account associated with the bank account has experienced a SIM swap within the last 48 to 72 hours. Additional verification is required if there is a swap detected in that period.

To The Death?

Overall, things look grim for SMS as a secure authenticator. The protocols and services that support it are riddled with vulnerabilities, sporting a rich history of exploits and fraud. NIST may have allowed SMS authentication to keep its ear. Still, the telecom troublemaker is no Evander Holyfield: it’s unlikely to topple the Tyson-like ferocity of the Microsoft Authenticator’s tight-lipped security.

However, perspective is magical: even after losing to Holyfield, Tyson is easily one of the greatest boxers in history. Similarly, SMS-based MFA remains infinitely better than nothing: the risks must be understood. Tech giants Google and Microsoft abundantly admit that any MFA enabled for an account prevents the overwhelming majority of brute-force or credential-stuffing attacks that have compromised many company networks.

Additionally, though SMS is inferior to using an authenticator app, the margins are small. NIST defines three levels of “authentication assurance” (AALs) which describe how strong an information system’s authentication methods are. Microsoft has mapped the authentication methods that it supports onto these AALs to provide a clear correspondence between NIST’s standard and Microsoft’s implementation. As per this documentation, authentication via the Microsoft Authenticator app can, at best, fulfill AAL 2, the middle level of authentication strength. Using a password plus a one-time code from a phone SMS out-of-band device equally fulfills AAL 2. This means that the official stance from Microsoft and NIST is that phone SMS and Microsoft Authenticator provide the same level of authentication strength. The difference is simply in the risks inherent to telecommunication networks.

However, though SMS authentication is vulnerable to SIM swapping and SS7 exploits, all authentication methods offered by either SMS or the Microsoft Authenticator app are susceptible to phishing attacks. MFA fatigue attacks are those to which only some versions of the Microsoft Authenticator app are vulnerable. Fatigue attacks work by spamming a user’s account with multiple logins requesting login approval via push notification. Eventually, the user may approve the login, either out of annoyance or by mistake, letting the hacker into the account, where they can modify other parameters to give themselves persistent access. The latest version of the Microsoft Authenticator app uses number matching (where the user must enter the specified two-digit number into the push notification to approve the sign-in), which largely mitigates MFA fatigue attacks.

However, the most common method of compromising accounts is via phishing emails that lead to websites tricked out to perform attacker-in-the-middle (AiTM) attacks. This is why NIST recommends using phish-resistant MFA, such as asymmetric key cryptography, such as FIDO2 keys, along with biometrics (a true, in-depth exploration of phishing-resistant MFA is beyond the scope of this article; source). I have responded to multiple phishing alert tickets where the email did not contain malware but rather links or attachments that led to web pages designed to steal credentials and bypass MFA. AiTM attacks don’t care whether you use the Microsoft Authenticator app or phone SMS for authentication: they’ll steal your lunch either way, as long as you cooperate by providing genuine credentials to their fake website.

In fact, AiTM attacks work by almost literally stealing lunch. However, instead of stealing your sandwich, they take dessert: your cookies.

Figure 1 source: https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/

The phishing links make the user think that they are logging into Microsoft’s user portal when instead, the user is providing login credentials (in real-time) to the attacker. The attacker then takes the session cookie, which is provided once the user has authenticated, and uses it to perform illicit actions as the compromised user.

For most companies, implementing truly phish-resistant MFA is out of reach. All the feasible options for small- to medium-sized businesses (SMBs) are equally susceptible to phishing-based attacks.

The Winner

We’ve seen phone SMS take a dizzying barrage of hits, from SS7 vulnerabilities to the prevalence of SIM-swap fraud. We’ve also seen the playing field level out, with the Microsoft Authenticator app performing a little better than SMS in NIST’s official authentication strength classifications. In addition, there is no difference between SMS and app-based authentication concerning AiTM phishing attacks, among the most common methods leveraged against accounts protected with MFA. Moreover, SMS authentication is more familiar and comfortable for tech-wary users: text messages are likely a consistent part of their daily life and communication. This can facilitate MFA adoption across a company, though users may still need to transition to stronger forms of authentication later on.

There have also been attempts to harden the SMS infrastructure so that texts can be sent consistently and securely. One paper even proposed a lightweight, alternative protocol to provide stronger end-to-end encryption for OTP codes and sidestep SS7 rerouting attacks.

Though inferior in absolute security to the MFA methods offered by the Microsoft Authenticator app, SMS may still have a future within the implementation of ubiquitous MFA. Though the security of telecom systems has improved with the advent of 4G and 5G networks and the use of the Diameter protocol, the hodge-podge heterogeneity of new networks with old ones still leaves SMS security in the shape of a murky question mark.

The Microsoft Authenticator app, however, trims off the security variables inherent in SMS and presents a straightforward solution unencumbered by the legacy vulnerabilities that plague the telecommunication architecture. Though it also offers users more of a learning curve than SMS, its enhanced security provides peace of mind to hacker-harried managers and network administrators.

However, both SMS and the Microsoft Authenticator app provide the same level of authentication assurance. Though NIST provides some caveats for using SMS in an organization, the app’s push notifications and SMS’s one-time codes hold the same status within the NIST authentication architecture. Additionally, both app and SMS are equally susceptible to phishing-based AiTM attacks, one of the most widespread methods of account compromise.

Cybersecurity is all about risk: removing, mitigating, and constantly accepting risk. The threats an organization faces with MFA enabled are exponentially more minor than those without it.

There are risks associated with using the Microsoft Authenticator for MFA, and a few more are associated with using SMS. A company could create policies that only allow SMS authentication from certain trusted geographic areas or IP addresses while requiring stronger forms of authentication for more unusual sign-ins. They could avoid SMS entirely or upgrade every user to use FIDO2 keys for authentication.

Implementing cybersecurity is a multi-faceted process that faces an ever-changing environment. Risks and best practices change: the only requirement is to stay abreast of them. SMS is down but not out, the Microsoft Authenticator app is up but not perfect, and user error is the perennial hobgoblin in the closet.

Stay sharp, stay vigilant. The winner in the cybersecurity world is the person who knows the most and uses that knowledge the best they can with limited resources. Your resources and decisions are yours to command. I only hope to provide a little more knowledge to your arsenal so that you can make your information much safer.

Cybersecurity Awareness Poster

Click here for a cybersecurity awareness training poster that Intrada Technologies clients may print and post to meet cybersecurity insurance requirements.

Tech Talk Articles

Contact Us

Office Hours

Intrada Technologies

Connect with Intrada