Developments to WebAuthn and the FIDO2 Framework
Since my last blog post on WebAuthn eight months ago, there has been a massive amount of progress made by both vendors and the authors of the specification to bring this spec into usage in browsers and websites. As of September 2018, there is support for Web Authentication (WebAuthn) in the stable builds of Chrome, Firefox and Edge. While the implementations may vary slightly between the three browser builds, we are well on our way toward the passwordless future set out by WebAuthn and the FIDO Alliance.
Additionally, the FIDO Alliance has begun to hold plenary meetings to discuss things like how account recovery should work and best practices for implementation, and interoperability events aimed at getting vendors on the same page with their development versions of the WebAuthn specification.
One of the big contenders that showed up on the FIDO Alliance and WebAuthn scene is Mastercard, and some FIDO messaging has begun to position WebAuthn as a tool for handling identity in regards to payments over the web. This is a great step, because organizations like Mastercard have a massive user base, and their backing of the spec could help drive mass adoption.
The impetus for payment providers and other companies to adopt this spec, and even use it as their default authentication mechanism, is a bit of a no-brainer. Aside from eliminating passwords, which are notoriously insecure, implementing WebAuthn gets rid of a substantial attack surface for organizations.
With WebAuthn, if an organization’s user credential database is compromised by an attacker, nothing has really been gained by the attacker. There’s also no easy way to phish for users’ credentials for the same reason; the user credentials are unique and scoped to a single organization. Implementing WebAuthn gets rid of the costs and need to handle fraud and attacks related to managing passwords.
The FIDO2 Framework
So, back to developments in the spec. One of the biggest changes to WebAuthn came earlier this year in April right before the RSA Conference, when WebAuthn received a bit of a “rebranding” with the announcement of its inclusion in the “FIDO2 Framework.” This led to WebAuthn to often be referred to, in part, as FIDO2 authentication, which can be a bit confusing for folks. While the two terms are used interchangeably sometimes, the FIDO2 Framework actually includes a second specification called CTAP, or Client to Authenticator Protocol. To make things more confusing, while CTAP can be supported in Web Authentication flows, we are actually going to be using CTAP2 in WebAuthn’s final form.
So what is FIDO2? CTAP2 and WebAuthn, together. The FIDO Alliance has begun to concatenate the two seperate specifications into the single namespace of FIDO2. CTAP2, an updated version of the Client To Authenticator Protocol previously used for FIDO’s U2F framework, includes updates to how data is transported and has parameters specific to WebAuthn that are provided to authenticators. Both CTAP1 and CTAP2 have a great amount of interoperability, and most authenticators you could use for WebAuthn right now, like Yubikeys, can indirectly support CTAP2 requests by mapping them via the client API to CTAP1 transports.
Before you go and pull up the CTAP specifications, it is important to note that having a working knowledge of what CTAP does is important, but not necessary for adding WebAuthn to your website. The Client to Authenticator Protocol, as the name implies, is specific to the client and authenticator, and unless you’re creating a new browser, or hardware or software-based authenticator, you probably don’t need to worry much about the finer points of this specification. Most user clients implementing WebAuthn already support CTAP2 with the only exceptions currently being Firefox and Safari.
Yubico has already started shipping FIDO2-specific keys, meaning keys that are made to support CTAP2, and as FIDO2 gains traction, we can expect the same from other groups like Feitian and Google.
New Technical Developments
The implementation of WebAuthn has been rapid in most major browsers this year as changes to the technical details of the spec have slowed. Now that WebAuthn has entered Candidate Review with the W3C, browser development groups can proceed without uncertainty of major elements of their implementation changing with updates to the spec documents.
Before talking about the technical developments in browsers, one of the big changes on the technical side of the WebAuthn spec has been how attestation statements are handed from the authenticator back to the browser. The attestation statement, which is provided by the authenticator to prove it created the credential for a given site, could potentially be used to track a user across multiple sites.
The attestation statement could include attributes unique to the user’s authenticator, so in order to mitigate this issue, recent versions of browsers implementing WebAuthn, specifically Chrome and Firefox, will present users with a modal asking if they want to include the attestation data when they authenticate with a site.
Graphic concept source: Adam Powers, Former Technical Director and current Technical Advisor @FIDOAlliance. Founder WebAuthn Consulting.
There are still elements of the specification that aren’t currently working in browsers although talked about in the W3C documentation, specifically, the authentication types described that allow for Android devices to be supported natively as authenticators by the API.
There have, however, been applications like Krypton, that allow us to override the API in Chrome and use the phone as an authentication device. Krypton achieves this by using a Chrome extension that pairs with a user’s phone, which then intercepts requests to the credential API, using the phone in part to create the WebAuthn credential.
The Microsoft Edge team has caught up with Firefox and Chrome in the last few months, and added support for WebAuthn to Edge browsers running on Windows 10. Additionally, their implementation supports Windows Hello, which is a great advancement at this stage in the spec’s development, since most users like myself are only testing operability with external hardware tokens. Users with a Windows device that supports Hello, like the Windows Surface Pro, can use their face as their biometric login for websites with WebAuthn support. Visit webauthn.io with a Windows Hello device for the demo.
Google and the Chrome Web Identity team have been killing it in new developments for WebAuthn within Chrome. As of writing this, there are two new feature flags in Chrome Canary version 69, the first one for adding native support of the MacBook Pro’s TouchID to Chrome, and it currently works!
The second flag is there to develop handling cloud-assisted bluetooth, or caBLE, for WebAuthn. The caBLE extension would allow for most likely Google-specific devices to pair using Bluetooth, but with little to no need of going through the standard pairing protocols that are currently used. While public information on caBLE is limited, it would be a great way to handle WebAuthn in a closed or offline environment as well.
Next Steps
If you haven’t checked out any code for it, there are now many examples of WebAuthn applications on GitHub. James Barclay, a fellow researcher at Duo Labs, and I still have two example applications written in Go and Python that show how WebAuthn works, and the Go version is hosted here if you prefer a quicker demo.
This is a good time to develop your own WebAuthn application, too, since the credential API is not expected to change much. If you’re already working on your own code, the FIDO Alliance has been developing conformance tools for testing FIDO2 operability, so folks that have made their own production-ready implementations of WebAuthn/FIDO2 architecture should put their code to the (unit) test!
So, even though the code hasn’t been changing much, there are other things that the FIDO Alliance has been focusing on that you can follow along or get involved with. One working group within the FIDO Alliance that I have been involved with concerns how account recovery will work with sites using FIDO2 framework. Account recovery when a user loses their authenticator is an interesting issue with regards to passwordless authentication, because some of the most obvious solutions could introduce additional problems.
For example, a solution such as “adding additional authenticators to an account” could be troublesome because it would require a user to have an additional, and often expensive, secondary authenticator to fall back on. There are myriad other solutions being thought about, but it is an interesting thought experiment to weigh the pros and cons of account recovery methods for passwordless authentication.
WebAuthn and FIDO2 as a whole is well on its way to being introduced to the world as an actual replacement to passwords, and the Duo Labs team and myself will continue to excitedly follow its progress. Feel free to contact me on Twitter if you have any questions and continue to be excited for WebAuthn!