Security news that informs and inspires

Make It Harder to Phish One-Time Passcodes Sent Over SMS

By

A proposal that would standardize the format of SMS messages being used in two-factor authentication schemes has a simple goal: make users relying on those one-time passcodes less susceptible to phishing attacks.

The idea is to create a common format for SMS messages that mobile browsers would recognize as two-factor authentication prompts so that browsers can complete the login operation, Theresa O’Connor, an Apple engineer working on WebKit, the browser engine used by Safari, wrote on GitHub. If the browser knows the passcode is intended for a specific organization, it would extract the code only for that organization’s website and not for any other URL.

Many organizations implement two-factor authentication on user accounts by relying on one-time passcodes sent via SMS. However, users can be tricked into giving up those passcodes. For example, if the user submits the username and password into a site that looks very much like the mobile banking site, the attacker can prompt the banking application to send a one-time passcode to the user, who winds up entering it into the fake site. With a standard format, the browser (or the application) knows the URL the code is intended to be used, making it less likely the user would fall for a scam and enter the code into a phishing page.

“The goal is to allow service providers to annotate their one-time code messages with an origin, so that user agents can only assist with providing the code to websites when there’s an origin match,” Ricky Mondello, a senior software engineer at Apple and a member of the WebKit Open Source Project wrote on the proposal repository’s issue tracker.

Simple Format

Under the proposed specification, the text message would be formatted in two lines. The first line is designed for the user, as it clearly displays the site generating the code and the code itself. The second line is designed specifically for the mobile browser or the application, so that the code is extracted and auto-populated into that URL. The browser will not autofill the code into whatever page the user has open.

747723 is your XYZ.com authentication code.
@XYZ.com #747723

If the user is on a phishing site, the browser would not auto-populate the passcode because the URL in the message would not match the page in the browser. The user will note that the auto-complete failed, and hopefully check the URL and realize something is wrong.

Apple introduced a security code auto-fill feature in iOS 12, which automatically reads passcodes from SMS messages and fills them in on the originating site. The proposal attempts to improve security and usability.

The proposal is not a requirement for having SMS for two-factor-authentication. Sites don’t have to follow the format—and it is up to the browsers and user agents on how they handle these messages. But it does bode well for the proposal’s future that Sam Goto and Steven Soneff, members of the Blink team (what Google calls its fork of WebKit), provided early feedback. Users would be better protected if other browsers, especially those not using Webkit (such as Mozilla’s Firefox) would also adopt the proposal. Microsoft’s Edge browser uses Blink on Android and WebKit on iOS.

Safer for Users

The standard format is just the first step. This proposal wouldn’t be as effective without an accompanying user education program, since users have to recognize that not auto-completing means there is a problem. Otherwise, there is the risk of the user thinking it was weird that the application didn’t handle the code and just manually enter the code anyway.

“It’s a step toward a safer user experience,” said Nick Mooney, a Senior R&D Engineer at Duo Security's Duo Labs.

There has been a lot of discussion over the years about how SMS messages are less secure compared to other two-factor authentication methods such as authenticator apps, the WebAuthn standard, and hardware tokens. While the National Institute of Standards and Technology initially suggested deprecating SMS messages in favor of other methods in the draft version of the authentication guide, it dropped that language in the final version (released in 2017). Instead, NIST recommends that if out-of-band authentication is used via SMS, "the verifier SHALL verify that the pre-registered telephone number being used is associated with a specific physical device." However, NIST acknowledged the risks of using SMS to deliver one-time passwords, such as "device swap, SIM change, number porting, or other abnormal behavior."

This proposal wouldn’t solve all the problems associated with phishing and one-time passcodes, and it isn’t claiming that it will. This is one of those situations where the proposal has a very specific problem it wants to fix and is focusing only on just that.

The good thing about this proposal is that it is pragmatic. Even though there are stronger, better, two-factor authentication methods, it recognizes that many organizations are still using SMS.

"While WebAuthn is the way we want to go, I think it's important that we still care about where folks are at and aim to make their experience as good as possible," said Jordan Wright, principal R&D engineer at Duo Labs.

Twitter two-factor authentication SMS message Two-factor authentication message for LinkedIn Two-factor authentication for PayPal

Currently, SMS messages come in many different forms. Examples from LinkedIn, Twitter, and PayPal.