Why is SMS OTP not as secure as Authenticator Applications such as Microsoft Authenticator?

Question

Why is SMS OTP not as secure as Authenticator Applications such as Microsoft Authenticator, etc? Is it because of snooping of mobile communications? or?

Answer 1

A few reasons:

1. It's relatively easy (though getting harder, thankfully) for an attacker to hijack somebody's phone number; the attacker convinces the cell provider to either port the victim's number to the attacker's plan, or the attacker gets a new SIM with that number. Then the attacker gets the victim's SMS messages.
2. SMS security over the air is almost nonexistent. I know somebody who accidentally intercepted some while hacking on a microcell. If you are near the target, or able to tap into the mobile network, you can just pick the SMS up on its way to the user.
3. SMS often goes through a number of hops even before reaching the tower, and some of those can be entirely unencrypted. An attacker who can tap the mobile operator's network - either cables or things like microwave transmission - can likely pick up SMS that way.
4. SMS is often less secure on the end device. For example, lots of people have their phones configured to show SMS on the lock screen, which is useful to an attacker if they steal a phone.
5. Similarly, if an attacker steals a phone and the owner doesn't deactivate the line fast enough (and the SIM doesn't have a passcode, which most don't), the attacker can potentially remove the SIM and use it in their own device to steal SMS, or hard-reset the phone and then use it to receive SMS. In either case, OTP keys would not be available in the same way.

---

EDIT: It was pointed out that I should cover how authenticator apps work, for contrast.

Authenticator apps generally work in one of two ways: TOTP, or push authentication.

TOTP, or Time-based One-Time Passwords, are the familiar codes, usually six digits, that change every thirty seconds. They are generated by cryptographically combining the current time (in thirty-second blocks) with a symmetric key (the key is most of what is stored in the QR code you use to add a site to your authenticator app). TOTP is a form of zero-knowledge proof of knowledge where the user proves they know the symmetric key, without ever transmitting the key itself. Once a given code expires it is useless; even with many codes and knowledge of when they were valid, it is approximately impossible to determine what the key that generated them might be.

• The key is only given out once, to a user authenticated by means often more secure than what mobile operators use (prevents attack 1).
• It's transmitted over TLS (usually HTTPS), which is way more secure than the mixture of plaintext and weak encryption used for SMS (this prevents attacks 2 & 3).
• Once the app is set up, that key is never transmitted anywhere ever again; it becomes literally just "something you have" and not under anybody else's control (prevents all the attacks common to SMS except 5).
• The user has to unlock the phone and launch the app to view the code; this prevents attack 4.
• The key is stored within the app, possibly encrypted by the app itself and almost certainly (on modern devices) encrypted by the OS as well; it is not stored on the SIM card or any other removable component, and if the phone is factory reset then the key is erased (prevents attack 5).

Push authentication takes a different approach: instead of exchanging a key once and then never directly communicating with the app again at all, the key is used to maintain (or re-establish on demand) a secure connection between the app and the server. The server can then, at any time, tell the app to prompt the user to confirm or deny authentication (push an authentication request to the user via the app). Unlike TOTP, which is a standard supported by many apps (although the details are sometimes varied), there are many ways to do push authentication and it usually depends on the user having the one app a particular site supports (which means you may end up with a lot of apps). One common approach is that the site or service sends a special kind of mobile network command, similar to an SMS, that tells the phone to wake up and check the Internet for notifications (this is how push notifications in general work). There will be a notification (typically using an OS-specific notification framework) telling the OS to wake up the authenticator app in particular, have it connect to the Internet, and authenticate to + check for incoming requests from its server.

However, all push authentication methods have the following properties:

1. While the push to wake the app up might be intercepted or go to wrong device, that's not enough to spoof the user's response. The app has to send an authenticated message back to the server telling it what the user's response to the push was. An attacker won't have the app's credentials for that user, so the attacker can't forge the user's response to the app's associated server. There's nobody an attacker can trick into believing is actually you. This prevents attack 1.
2. The app proves its identity (authenticates) to the server (using some internally-stored key) before the user's authentication can occur (unlike SMS, which just transmits the code out to everybody who may be listening). The app's authentication goes over TLS. This prevents attacks 2 & 3.
3. The app secures its authentication secrets within its private storage, usually encrypted by the app, the OS, or both. The secrets can't (practically) be physically removed from the phone, and resetting the phone wipes them. This prevents attack 5.
4. The app generally can't (and wouldn't try to) display a push authentication request on the lock screen (it might let the user know that there is one, but usually won't even say where from). The app (and/or OS) definitely won't let the user respond to the push without unlocking the phone, and sometimes without additional authentication (e.g. fingerprint) to the app itself. This prevents attack 4.

---

Somewhat off-topic, but...

Mind you, if you want really good security, you should look at FIDO2/U2F/WebAuthn, which uniquely provide a level of security not offered by other second factors: protection against phishing pages. The way these protocols work, the browser or other app tells the authenticator what site/app is requesting access and uses that cryptographically; a phishing site that is a lookalike domain will still not work for authenticating to the actual target site.

Although usually associated with dedicated hardware tokens (e.g. Yubikeys), there's actually WebAuthn/FIDO providers in many platforms (Windows has Windows Hello which works with memorized secrets, physical authenticators, or biometrics; Apple has TouchID and FaceID; Android has support for using the unlock methods such as PIN or diagram or biometrics). Using this, you can potentially achieve three-factor authentication (knowing password + having phone + being the person with your fingerprint) and defeat phishing attacks while also being able to log in by just tapping your fingerprint reader instead of needing to open an app and copy a code.