WebAuthn (Web Authentication) is an effort by the World Wide Web Consortium (W3C),^[1][2] with input from the FIDO Alliance,^[3] to standardize an interface for public-key authentication of users to web-based applications and services. It implements an extension of the W3C's more general Credential Management API, which is an attempt to formalize the interaction between websites and web browsers when exchange user credentials.

WebAuthn can be used in a single-factor capacity, whereby the user does not have to provide any additional information, such as username and passwords. However, for additional security, the party asking for authentication can still require those characteristics, effectively making this a multi-factor authentication scheme. Optionally, this can also be combined with other authentication factors, such as gestures or biometric verification, which improves overall security, while it is still unnecessary for users to type in long, complex strings of characters.

WebAuthn can be implemented in a variety of different ways, since the underlying cryptographic operations are performed by an "authenticator", which is an abstract functional model that is mostly agnostic on the details of how the key material is managed. This makes it possible to implement WebAuthn purely in software, but also to make use of a processor's trusted execution environment or a Trusted Platform Module (TPM). Sensitive cryptographic operations can also be offloaded to external hardware tokens that can in turn be accessed via USB, Bluetooth Low Energy, or near-field communications (NFC). This, in general, is more secure, as private key material is at no time accessible to software running on the host machine. The communication with external hardware tokens is designed to work with the Client-to-Authenticator Protocol (CTAP), making WebAuthn effectively backward compatible with the Universal 2nd Factor (U2F) standard.

WebAuthn as well as CTAP are both outgrowths of the FIDO2 project^[3], which tries to standardize on secure and password-less authentication schemes and goes beyond the scope of browsers and the Web. It is based upon previous work done by the FIDO Alliance, in particular the Universal Authentication Framework (UAF) and Universal 2nd Factor (U2F) standards.

Application and device support

The WebAuthn Level 1 standard was published as a Candidate Recommendation by the Web Authentication Working Group on March 20, 2018.^[1] The desktop version of Google Chrome has supported WebAuthn since version 67.^[4] Mozilla Firefox, which had not fully supported the previous FIDO U2F standard, included and enabled WebAuthn in Firefox version 60, released on May 9, 2018.^[5] The current Windows Insider release of Microsoft Edge implements a version of WebAuthn that works with both Windows Hello as well as external Security Keys.^[6] Support that matches the published standard is expected later in 2018.^[4]

Existing FIDO U2F Security Keys are largely compatible with the WebAuthn standard, though WebAuthn added the ability to reference a unique per-account "user handle" identifier, which older hardware tokens are unable to store.^[1] The first new token able to handle the new "FIDO2" style of key storage is the second-generation Security Key by Yubico, announced on April 10, 2018.^[7]

Dropbox announced support for WebAuthn logins (as a 2nd factor) on May 8, 2018.^[8]

API

The WebAuthn API extends the Credential Management navigator.credentials.create() and navigator.credentials.get() JavaScript methods so they accept a publicKey parameter. The create() method is used for registering public key authenticators as part of associating them with user accounts (possibly at initial account creation time, but more likely when adding a new security device to an existing account), and the get() method is used for authenticating (such as when logging in).

To check if a browser supports WebAuthn, scripts should check if the window.PublicKeyCredential interface is defined. In addition to PublicKeyCredential, the standard also defines the AuthenticatorResponse, AuthenticatorAttestationResponse, and AuthenticatorAssertionResponse interfaces in addition to a variety of dictionaries and other datatypes.

The API does not allow direct access to or manipulation of private keys, beyond requesting their initial creation.

Criticism

In August 2018, a team of researchers from Paragon Initiative Enterprises did a security audit of the upcoming WebAuthn standard. While they could not find any specific exploits, they revealed some serious weaknesses in the way the underlying cryptography is used and mandated by the standard.^[9]

The main points of criticism evolve around two potential issues that were problematic in other cryptographic systems in the past and therefore should be avoided in order to not fall victim to the same class of attacks:

• Support for RSA with PKCS1v1.5 padding is required by the WebAuthn standard. This particular scheme of padding is known to be vulnerable to specific attacks for at least twenty years and it has been successfully attacked in other protocols and implementations of the RSA cryptosystem in the past. It is difficult to exploit under the given conditions in the context of WebAuthn, but given that there are more secure cryptographic primitives and padding schemes, this is still a bad choice and is not considered to be best practice among cryptographers any more.

• The FIDO alliance standardized on an asymmetric cryptographic scheme called ECDAA.^[10] This is a version of direct anonymous attestation based on elliptic curves and in the case of WebAuthn is meant to be used to verify the integrity of authenticators, while also preserving the privacy of users, as it does not allow for global correlation of handles. However, ECDAA does not incorporate some of the lessons that were learned in the last decades of research in the area of elliptic curve cryptography, as the chosen curve has some security deficits that is inherent to this type of curves and reduces the security guarantees quite substantially. Furthermore the ECDAA standard involves random, non-deterministic, signatures, which already has been a problem in the past.

The auditors from Paragon Initiative Enterprises also criticized the way in which the standard was initially developed, as the proposal was not made public in advance and experienced cryptographers were not asked for suggestions and feedback. Hence the standard was not subject to broad cryptographic research from the academic world.

Despite these shortcomings the researches from Paragon Initiative Enterprises still encourage users to continue to use WebAuthn, but came up with some recommendations for potential implementors and developers of the standard and hope that this can be fixed, before the standard is finalized and therefore set in stone. Avoiding such mistakes as early as possible, will prevent the industry from any challenges that are introduced by broken standards and the need for backwards compatibility.

References

External links

• Web Authentication: An API for accessing Public Key Credentials Level 1
• Web Authentication Working Group
• Web Authentication API on MDN