Multi-factor authentication with U2F

User-selected passwords are a perpetual weak link in the online security chain, a particularly troublesome one where web services are concerned. An industry group called the FIDO Alliance published an open specification for two-factor authentication hardware earlier this year, along with complementary standards intended to lay out a uniform API for web services to utilize such hardware. The goal is to simplify the process of offering multi-factor authentication for users, courtesy of a vendor-neutral standard.

FIDO's membership includes a mix of banking institutions, software companies, and hardware manufacturers. Included on the list are Google and Microsoft, two of the four biggest web browser makers. One noticeable absence is Mozilla, but security-token vendor Yubico (makers of the YubiKey line of USB one-time password (OTP) tokens, which we looked at most recently in April) is a member.

Yubico is evidently working on producing hardware tokens that implement the FIDO Alliance's new specification, called Universal 2nd Factor (U2F). Given the company's substantial suite of free-software utilities and frameworks for its existing products, it is presumably interested in working with free-software browsers on U2F as well.

The FIDO Alliance was launched in early 2013, although the first public draft of U2F was only published in February 2014. It remains a draft at this stage.

U2F specifies a protocol for users to register a hardware authentication token with a remote web service, so that on future visits, activating the token sends an unforgeable identifier that is unique to the token-and-service pair. As the name indicates, U2F is not meant to replace passwords entirely, but to augment them as a "second factor." The specification dictates that the token has some form of user-activation: a button, some form of biometric scanner, or so on. At present, the specification also describes a USB messaging format for the token to communicate with the user's local web browser—although it is expected that additional transports (namely NFC and Bluetooth) will also be supported.

The full specification is available for download on the FIDO Alliance site. Separate documents describe the JavaScript API for communicating between the browser and a remote web service, the message format between the browser and the hardware token, and the identity-assertion scheme that the token uses to verify that only an authorized application (for now, a category that includes only the web browser) is sending an authentication request. On the same download page are a separate set of specifications for FIDO's other major project, the password-replacement scheme called Universal Authentication Framework (UAF)—which is not connected to U2F.

One distinguishing feature of the scheme is that the U2F hardware token is not tied to a specific service or web site. Rather, whenever the user registers an account with a new web service, a new public/private key pair is generated on the token. The public key is sent to the service, while the private key remains on the device, which, naturally, must be tamper-proof so that the keys cannot be extracted. Similarly, if the token incorporates a biometric identifier or any other sort of local authentication information, that data must also be stored on the token and not be readable. On repeat visits, the web site sends a challenge to the browser, which the hardware token signs using the private key and returns.

Also worth noting is that U2F leaves quite a bit of the hardware device's design and feature set undefined. The example usage scenarios in the Yubico talk involve a simple, inexpensive token much like Yubico's existing product line: a simple button press when the token is plugged in to the computer is the only authentication performed for the device itself. But more complex devices could be produced, which require the user not only to possess the hardware token, but to enter a password on it or (for example) perform a fingerprint swipe. In the accompanying blog post, Yubico notes that its NEO line of tokens is designed to run Java applets, which could include U2F service registration and authentication, although it also points out that current NEOs do not support U2F and may not be upgraded in in the future.

On the other hand, the specification does dictate that the hardware token does not include a global identifier that can be accessed by the web services. This is a privacy protection; there is intentionally no way for a web service to determine whether or not any two U2F accounts are authenticated with the same hardware device. Similarly, a web service cannot dictate that a particular brand or type of hardware token be used: all it knows is that a U2F-compliant device is available and is used in the authentication stage. In response to an audience question on the Mozilla video, Yubico representative Jerrod Chong said that implementation tests have verified interoperability between four hardware vendors.

Whether the hardware token is simple or complex, a great deal of U2F's security also relies on the browser implementation. The browser must handle the registration of new services, verify the remote server's identity, send the authentication challenge from the site to the hardware token, and send the cryptographically signed response from the token back to the service. Naturally, all of these steps need to handled by the browser natively, not by running HTTP-delivered JavaScript code. The browser must also implement the U2F raw messaging protocol over USB HID. At present, the USB Implementers Forum has not yet approved the U2F protocol, although FIDO expresses confidence that such approval will happen in due course.

On July 30, Yubico posted on its company blog that it had met with Mozilla to present a case for adopting U2F. Evidently Yubico's presentation to Mozilla was an effort to prompt the browser maker into starting its own U2F implementation effort. As of now, there does not seem to be any formal progress on that front, but many in the audience for the video seemed supportive of the concepts. It is also possible that Yubico or another interest party will write code of its own to contribute; time will tell. Video from the presentation and subsequent question-and-answer session is available from Mozilla.

U2F is interesting from a security perspective, perhaps most of all in how it presents a very different alternative to WebCrypto for the future of browser security. U2F arguably offers stronger security, since it mandates tamper-proof hardware and does not rely on susceptible-to-man-in-the-middle JavaScript.

But strong cryptography is not everything; if it were, every email would be sent with OpenPGP encryption. Yes, U2F seems to offer a simple user experience, which is an absolute requirement if the feature is ever to extend beyond the smallest niche. The inescapable downside, however, is that users will be required to purchase and keep track of the hardware devices themselves. An industry-wide standard may help; costs could certainly fall if not every vendor needs to reinvent the wheel.

But any cost greater than zero will no doubt prompt some percentage of users to skip the option completely. It is anyone's guess how large that percentage will be. Unless the authentication devices are offered for free or as cheap add-ons for more expensive devices, not everyone will use them. Regardless of the scale or speed of U2F uptake, of course, both the browsers and site owners will need to support older, less secure authentication methods for many years still to come.