Here’s How Apple Plans to Make SMS Two-Factor Authentication More Secure

Engineers at Apple have put forward a clever new idea that could help improve the security of one-time passcodes sent by SMS text messages to both harden them against phishing attacks while also making it easier to use them for two-factor authentication.

The proposal, which was published on github and shared by ZDNet, comes from Apple’s WebKit engineers, who make up the team that develops the core engine for Safari, and primarily suggests a way of associating a one-time code delivered in an SMS message to the server that it actually came from.

As things presently stand, most sites and services that use SMS to send out one-time codes simply list the code and usually provide some indication of the name of the site. The problem with this, however, as the WebKit team explains, is not only that there’s no guarantee that the code came from where it was supposed to originate, but there’s no way to programmatically tie the code back to the site where it’s supposed to be entered.

Suppose a user receives the message “747723 is your FooBar authentication code.” It’s possible, even likely, that 747723 is a one-time code for use on https://foobar.com. But because there is no standard text format for SMS delivery of one-time codes, systems which want to make programmatic use of such codes must rely on heuristics, both to locate the code in the message and to associate the code with the relevant website (origin). Heuristics are prone to failure and may even be hazardous.

This makes the current system more vulnerable to fairly common “man-in-the-middle” phishing attacks, where a hacker can create a fake site that’s pretending to be something like a legitimate online banking service and intercept the user’s one-time SMS password by tricking them into entering their code on the fake site; this code is then immediately replayed to the real site to gain access to the user’s actual account.

To address this, Apple’s engineers are calling for companies to adopt a standard for one-time codes for SMS authentication to ensure that codes can only be entered on the actual, legitimate site that they were intended for.

Sites should be able to trust that the one-time codes they send over SMS will only be entered on the originating site.

Apple proposes that SMS messages be associated with an actual URL rather than just a site or service name, and since SMS is a fairly basic, text-only format, the suggestion is simply that the URL be added into the SMS message itself.

However, the main point of this wouldn’t be to simply allow the user to see or tap on a URL — although that’s certainly another possibility as well — but rather to be able to read an incoming SMS message and extract the necessary information to allow it to be automatically entered, but only on the site where it’s supposed to be entered.

The Proposal

Apple already introduced a pretty useful feature in iOS 12 and macOS Mojave that automatically looks for incoming SMS OTP codes and offers to autofill them into Safari, which is a handy time-saver from having to copy-and-paste or retype a code after it comes in. However, since there’s currently no reliable way to tie that code to a specific site — in many cases iOS and macOS simply offer the most recent code that came in for whatever text field the user is currently filling in.

While this usually works well enough, since the user is likely still sitting on the sign-in page waiting for the code to arrive, there’s no way to secure this against man-in-the-middle phishing attacks, where the code could be even more easily autofilled into the wrong page.

To make this process more secure and prevent these kinds of attacks, Apple is proposing that SMS OTP messages adopt a standard format like the following:

747723 is your FooBar authentication code.

@foobar.com #747723

In this case, the first line of the SMS would be designed to be read by humans, while the second line, including the symbols, would allow Safari and other apps to programmatically extract the legitimate URL and code from the message without requiring any guesswork. Since a valid OTP can only ever be generated by the actual website, the URL would ensure that it could only be automatically entered where it’s supposed to be, and browsers like Safari wouldn’t even offer up the code unless the user was actually on that page.

Security of Two-Factor SMS

Although this proposal will help to harden against phishing attacks, SMS is still one of the less secure means of two-factor authentication available, since it can be prone to SIM swap attacks where a hacker gains access to your SMS phone number by porting it away from you.

Unlike phishing, however, SIM swaps are much more targeted attacks, as they require somebody to be after your phone number specifically. However, there are considerably more secure methods available, ranging from using TOTP apps such as Google Authenticator to generate your codes locally on your device to actual physical security keys that require you to connect a device to your computer or iPhone via USB, Lightning, NFC, or Bluetooth. This latter method is extremely secure not only against conventional hacking methods but also renders phishing attacks virtually impossible.

Wherever possible, we strongly recommend that users employ a more secure method for their high-security accounts such as online banking services and their email account. In the latter case, iCloud email users have Apple’s two-factor authentication available, while Gmail users can take advantage of Google’s Advanced Protection Program.

What This Means for You

The end result of this proposal would make it much easier to use SMS-based one-time passwords with fewer risks, and would also avoid some of the confusion that can occur with the autofill system that’s currently in place when users are signing into more than one site, since right now Safari can’t always determine which SMS OTP message to use for a given site.

While this wouldn’t stop you from manually entering a one-time code in the wrong place, Apple’s team actually hopes that once the proposal is adopted, they could also remove the manual autofill feature to allow the OTP code to be extracted and the two-factor login process to be completed automatically with little or no user intervention. Further, once the code comes in, Safari could alert users when the site that they’re on doesn’t match the one listed in the SMS message, strongly advising them not to enter the OTP code manually either.

Currently both Apple’s WebKit and Google’s Chromium engineers are on board with the proposal, while Mozilla’s FireFox team hasn’t provided any official feedback on the standard yet. While this proposal only addresses the browser end of the problem, once every browser adds support for it then most major providers that support SMS OTP codes should jump on board as well, as it requires only a relatively minor change on their part.