SMS, 2FA, and Authentication
I hate services which depend on the public switched telephone network (PSTN, i.e. “the phone network”), and especially the address layer (i.e. phone numbers). This is for several reasons:
Phone companies are often explicitly (public PTT) or legally de facto (due to laws like CALEA in the US) an extension of the government. They require offensive levels of identity documentation to open accounts (in many markets), and the massive trove of incidental intelligence collected from their operations (realtime location at all times with cellphones, patterns of communication “metadata”, and in some places, access to the unencrypted data and voice communications themselves) are easy for government to get.
PSTN is expensive and poorly run, compared to private networks. It’s a monopoly or regulated, so it’s not a free market to enter, and “international roaming” is very expensive compared to more pure Internet communications.
PSTN is very insecure — it’s not designed for robustness against real attackers today, both at the account level (where social engineering is a huge vulnerability) or at the network level (where it’s not as bad, but where network-level attacks are still quite possible.)
This is all bad for communications, but it’s unforgivable for identity and authentication. Outsourcing your IdP needs to the local telco is abjectly moronic. They’re not in that business, they’re not capable of doing that business, they’re not being compensated for that business, and in many cases their interests are actively opposed to yours and to providing that service well.
Unfortunately, they’re widely available, and an “almost good enough for some applications” solution here. Getting a phone number has some cost (unlike email, which is virtually costless), so it’s a somewhat viable anti-abuse system; requiring an attacker to demonstrate ownership of a unique PSTN address/phone number to create an account imposes a cost, so the attacker can’t have infinite separate accounts. Users tend to retain their phone numbers for a long time, and there are procedures and abstractions for re-assigning those numbers to new hardware devices for the user without requiring they retain ownership of a specific piece of hardware continuously, or even retain any specific secret knowledge. The phone companies make enough money from end user accounts to be incentivized to provide service on an ongoing basis, and to maintain phone accounts where possible. SMS is available on very low end phones (pretty much any cellphone and even some landline/VoIP services), and is available on all featurephones and smartphones, and doesn’t require permissions or sophisticated user to install or use (as might be required for FIDO keys, or authenticator software).
This is most relevant in the context of 2FA using SMS (although “authentication via automated voice call”, or “authentication via outsourced human call” also apply here), and especially for the use of 2FA-SMS as a true account recovery method, rather than simply a supplemental second factor.
In the true 2FA case, if a user selects a strong password, and SMS has been fully compromised, the user isn’t any less secure than he was with simply a secure password. As long as that password is unique/not re-used on sites which are separately compromised, is long/entropic enough to not be brute forced (and attempts rate-limited at some level; both in that attacks must be online and roughly serialized, and probably limited after a certain number of unsuccessful attempts, rather than in a downloadable password database which can be brute forced in parallel and offline), etc., the SMS second factor isn’t even particularly necessary. However, in the real world of weak end user selected passwords (low entropy, often re-used), 2FA of some form is quite useful, and at least 2SV is at least table-stakes.
I would generally argue for TOTP using an authenticator app as substantially superior to SMS based auth for 2SV or 2FA use, but all of this is markedly inferior to Security Keys/FIDO2/U2F, since those solve the phishing problem as well, or to the new Passkeys model (which is FIDO but doesn’t require dedicated hardware).
A problem with SMS is that “only the authorized user has access to his SMSes now, and only the user retains control of this number exclusively and forever” is violated in a whole bunch of cases.
The user might be using a prepaid phone and not renew, or allow the phone account to lapse. User might be moving between countries or other locations and get a new number. In this case, not only does the user lose access to his account, but a new user gets it (because the numbers are recycled.)
User might use a shared phone number, or access to the phone instrument/handset might be shared, either perpetually/frequently or intermittently.
User’s phone might be physically accessed (one time, or physically stolen). Some users allow SMS contents to be displayed on even a locked screen, so phone password might not be needed, or phone password can be defeated.
User might be convinced to forward messages, or do things which lead to forwarding authentication codes from messages. This is the famous telegram screenshot scam, where users are requested to take a screenshot which incidentally includes authentication codes.
Phone accounts can be social engineered to add new phones/redirect existing phones (“SIM swapping”) — usually this is by subverting employees at phone retailers and inadequate controls within the IT systems of those phone companies.
The PSTN itself isn’t as resistant to network attacks as cryptographically-strong systems are. SS7, the signaling protocol used, is basically a “trusted set of participants”; a badly-behaved participant, or someone who subverts one of their systems, can reroute calls (especially for a short period of time, at least 4 hours), intercepting messages. Employees at the telcos themselves also may have access in some cases.
These aren’t as common as “user picks a bad password” or “password to critical application is also the Netflix password, shared widely with others” or “password re-used and included in a breached site list”, but they’re also not things as easy for sites to resist, or end users to completely rule out in all cases, to the same degree.
The area where SMS is truly bad, but also solving a need which isn’t easily met by a TOTP authenticator app, is account recovery. Account recovery becomes a requirement in two main workflows: the user forgets his password and needs to reset it, or the user loses his computing device(s) (often a phone, either loss of hardware or OS reinstallation) containing his authenticator app, potentially passkeys, and potentially all saved information such as recovery codes.
In the current world, many consumer applications, and some business applications, will allow a user who has lost his password to recover the account simply through ownership of the associated email account, or in some cases phone account. This is the expected behavior for a password-only account, but in the case of a 2FA/2SV protected account, this presents a problem: what if the user has lost the second factor as well. This easily happens at the same time as losing the password if the user was relying on a saved password on his phone itself as the main password, and an authenticator app also installed on that same phone — both would be lost if the phone is reinstalled or replaced without backup and restore. Control over the email address could be assumed, but allowing the 2FA to be removed simply with control of the email address makes the 2FA pretty useless/reduced to just anyone controlling the email account can get control of the user’s account on your service. Often, what happens is the main password is reset through email, and the 2FA credential can be removed or restored through control of an associated phone number, either through an automated system or sometimes through some kind of manual customer service interaction. There are also services which don’t use email at all, and where the user is identified solely through control of a phone number, such as telegram, signal (although keys persist on the device), and many other mobile-focused new services.
This might be tolerable for low value consumer services, but the problem is what might be a low value consumer service for 99% of a service’s users might be a high-value, critical, revenue generating account for 1%, and that 1% are very important to the service. For instance, large-following Instagram accounts are frequent targets of attack, and compromise of that, or of a similar large-following Twitter account, can cause substantial harm.
There are also systems where much more than 1% of the users are likely to be high-value — many business applications, cryptocurrency exchanges and hosted wallet providers, etc. In those cases, some form of 2FA is needed, and accounts need to be recoverable, but the weaknesses of SMS as single-factor account recovery are probably unacceptable.
It’s pretty easy to solve the “better 2FA than SMS” problem for 2FA or SMS, but handling account recovery well remains a difficult problem. There are a lot of partial solutions, but they all involve tradeoffs — potentially more friction in the account recovery process, potentially “wiping” many of the details of recovered accounts (e.g. deleting all stored communications before turning it over), potentially a delay built into the recovery process (to give a legitimate account holder an opportunity to protest and block an illegitimate account recovery), and potentially things which add cost to the recovery process on either or both sides.
In light of all of this, Twitter’s decision to turn off SMS authentication as a 2FA method for free users is interesting, and something I support. It appears this was also motivated by the $60mm/yr scam third-world telcos were running vs. Twitter, but to the extent it pushes the market to better 2FA and account recovery procedures, it will ultimately be an improvement in security.
Ironically, Twitter used to run an in-house MFA system inside their installable application. It appears this was build by people from an acquisition, and when those people left the company (inevitable — this was Twitter after all), it was too difficult to maintain, so for a while they fell back to SMS-only as a means of 2FA. At various times they then allowed TOTP instead, but also made it difficult to remove SMS as a fallback or account recovery pathway.
It will be interesting to see how Twitter handles account recovery for users who aren’t subscribed to Twitter Blue (and thus don’t have SMS 2FA as an option), or who don’t have SMS 2FA configured as an option otherwise, but who have TOTP (or Security Keys) as their second factor. Right now, they make it very easy for any authenticated user with a 2FA system set to access/copy a recovery key (without re-entering a password or demonstrating ownership of 2FA), which essentially reduces the security of the system to login-protection-only — if a bad guy walks up to a user’s logged-in browser or phone client, he can take over the account permanently by copying the recovery code and using it to disable 2FA). This might be an ok tradeoff for low value Twitter accounts (but IMO probably isn’t, even then — at least require reauthentication, and if that fails/isn’t possible, add a time delay), but it’s definitely not an acceptable system for a high-value account (including high value Twitter accounts), particularly where leaving the session logged-in for long periods of time is expected/common (e.g. Twitter, but also an active trading workstation, or any other service used extensively by a user throughout the day, or a mobile app which doesn’t require re-authentication on each session.)
Ideally someone will solve the account recovery problem at scale; there are a lot of natural scale advantages to a solution. However, we don’t want to give control of authentication to an outsourced provider (to the extent we already do, like the old Facebook Connect, oauth2 with Google, Apple ID login, etc. is pretty dangerous and facilitates monopolies…). Account recovery itself might be a more acceptable thing to outsource on its own, separate from routine login, but the telcos are probably the wrong entity to do it, and SMS-auth is the wrong technology for it for moderate to high value applications.