Phishing Resistant SMS Autofill – The GitHub Blog

Google+ Pinterest LinkedIn Tumblr +

We recently shipped support for the origin-bound draft standard for security codes delivered via SMS. This standard ensures security codes are entered in a phishing-resistant manner. It accomplishes this by binding an SMS with the sending site’s origin. In addition, the standard defines a format that makes security codes easier for browsers and applications to parse, and removes the need for heuristics to support autofill.

  1. https://not-github.example that looks a whole lot like https://github.com.
  2. They enter their username and password. That username and password is sent to https://not-github.example, which proceeds to enter those credentials into https://github.com (a classic person in the middle attack).
  3. They are asked to enter the security code just pushed to their device via SMS:123456 is your GitHub authentication code.
  4. This person, not realizing they are on a malicious site, proceeds to manually enter the code into https://not-github.example, ultimately giving the security code to the attacker. The attacker enters the code themselves and is now logged in to GitHub.com as the user.

Security code autofill more or less just automated step 4, where the user manually entered the SMS code into https://not-github.example. Heuristics are used to assume that if a text is received and it looks like a security code, the user probably wants that code filled into an input box in the active window on their device. It is not substantially better or worse than manual entry from a phishing perspective.

The core issue with SMS security code phishing is that there was no way to bind the sender of the SMS to the site where it should be used. Apple realized this seemed like a pretty tractable problem with only small changes to the SMS messages sent to users. The origin-bound specification proposes that sites modify their SMS security code messages to include a “footer” where the last line of the message contains, in a standardized format, information about the sending site’s origin as well as the security code itself. For GitHub, our security code message now looks like this:

123456 is your GitHub authentication code.

@github.com #123456

This simple addition thwarts phishing attack because the autofill logic can ensure that it only autofills the code on GitHub.com. If the user is currently on https://not-github.example, the browser will refuse to autofill the security code. Technically, this information could also be used by a human entering the code manually as well. However, computers are incredibly adept at following simple rules with near 100% accuracy. Humans on the other hand are incredibly bad at this kind of thing. Research demonstrates that users are confused by URLs. It isn’t their fault; users were forced to deal with URLs to use the Internet, but it is not reasonable to expect those users to have a comprehensive understanding of the subtle security model associated with them.

Web OTP API. This proposal aims to standardize the way an SMS security code is fetched and auto-filled in clients. The upcoming Apple implementation uses the origin-bound standard, but the actual autofill implementation is proprietary and only available to Apple’s own browsers/devices. The Web OTP API proposes a standardized JavaScript API that platform owners could support. As of now, the proposal is only implemented on Android, but we will continue to monitor things to see if and when this proposal gains more broad adoption.

all of which are supported by GitHub.com) when faced with targeted attacks. However, there is a reason GitHub, as well as a number of other sites with savvy security teams (including Apple), continue to support SMS. The current data supports SMS still being quite effective against the most common attacks.

WebAuthn security standard, as it seems to present the rare opportunity to both dramatically improve security while being incredibly easy for everyone (particularly with “platform authenticators” such as Face ID/Touch ID, Windows Hello, etc). However, that standard is still in its infancy. We are following along and looking to see how we can make use of WebAuthn to improve security and usability. In the meantime, we will continue to look for ways we can improve the security of existing options as well. Origin-bound security code SMS delivery was one such improvement that required relatively minimal investment for the security benefit provided.

  Source Link

Share.

Leave A Reply