WebAuthn

FIDO2 is the successor to FIDO Universal 2nd Factor (U2F). Whereas U2F only supports multi-factor mode, having been designed to strengthen existing username/password-based login flows, FIDO2 adds support for single-factor mode. In single-factor mode, the authenticator is activated by a test of user presence, which usually consists of a simple button push; no password is required. In multi-factor mode, the authenticator (something you have) performs user verification. Depending on the authenticator capabilities, this can be:[12]

• something you know: a secret such as a PIN, passcode or swipe pattern
• something you are: a biometric such as fingerprint, iris or voice

Regardless of mode, the authenticator never shares its secrets or biometric data with the website.[13] Moreover, a single user's secret or biometric works with all websites, as the authenticator will select the correct cryptographic key material to use for the service requesting authentication after user verification was completed successfully.

A secret and biometric on the authenticator can be used together, similarly to how they would be used on a smartphone. For example, a fingerprint is used to provide convenient access to your smartphone but occasionally fingerprint access fails, in which case a PIN can be used.

Like its predecessor FIDO U2F, W3C Web Authentication (WebAuthn) involves a website, a web browser, and an authenticator:[1]

• The website is a conforming WebAuthn Relying Party
• The browser is a conforming WebAuthn Client
• The authenticator is a FIDO2 authenticator, that is, it is assumed to be compatible with the WebAuthn Client

WebAuthn specifies how a claimant demonstrates possession and control of a FIDO2 authenticator to a verifier called the WebAuthn Relying Party. The authentication process is mediated by an entity called the WebAuthn Client, which is little more than a conforming web browser.

Authentication

A typical Web Authentication (WebAuthn) flow

For the purposes of illustration, we assume the authenticator is a roaming hardware authenticator (see below for other options). In any case, the authenticator is a multi-factor cryptographic authenticator that uses public-key cryptography to sign an authentication assertion targeted at the WebAuthn Relying Party. Assuming the authenticator uses a PIN for user verification, the authenticator itself is something you have while the PIN is something you know.

To initiate the WebAuthn authentication flow,[14] the WebAuthn Relying Party indicates its intentions to the WebAuthn Client (i.e., the browser) via JavaScript. The WebAuthn Client communicates with the authenticator using a JavaScript API implemented in the browser. A roaming authenticator conforms to the FIDO Client to Authenticator Protocol.

WebAuthn does not strictly require a roaming hardware authenticator. Alternatively, a software authenticator (e.g., implemented on a smartphone) or a platform authenticator (i.e., an authenticator implemented directly on the WebAuthn Client Device) may be used. Relevant examples of platform authenticators include Windows Hello[15] and the Android operating system.[16]

The illustrated flow relies on PIN-based user verification, which, in terms of usability, is only a modest improvement over ordinary password authentication. In practice, the use of biometrics for user verification can improve the usability of WebAuthn. The logistics behind biometrics are still poorly understood, however. There is a lingering misunderstanding among users that biometric data is transmitted over the network in the same manner as passwords, which is not the case.[17][18]

The WebAuthn Level 1 standard was published as a W3C Recommendation by the Web Authentication Working Group on 4 March 2019.[8][9][21] WebAuthn is supported by Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari[9] and Opera.[22]

The desktop version of Google Chrome has supported WebAuthn since version 67.[23] Firefox, which had not fully supported the previous FIDO U2F standard, included and enabled WebAuthn in Firefox version 60, released on 9 May 2018.[24] An early Windows Insider release of Microsoft Edge (Build 17682) implemented a version of WebAuthn that works with both Windows Hello as well as external security keys.[25]

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 authenticators are unable to store.[1]

One of the first FIDO2-compatible authenticators was the second-generation Security Key by Yubico, announced on 10 April 2018.[26] The first FIDO2-compatible authenticators with a display was Trezor Model T by SatoshiLabs, announced on 6 November 2019.[27] Trezor Model T was also the first authenticator that allowed users to select which FIDO2 resident credential should be used directly on a device.

The first Security Level 2 certified FIDO2 key, called "Goldengate" was announced one year later by eWBM on 8 April 2019.[28][29]

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

Apple announced that Face ID or Touch ID could be used as a WebAuthn platform authenticator with Safari on 24 June 2020.[31]

WebAuthn 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 exchanging user credentials. The Web Authentication API[32][33] 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) while 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.

In August 2018, Paragon Initiative Enterprises conducted a security audit of the 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.[34]

The main points of criticism revolve 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:

• Through the mandated use of COSE (RFC 8152) WebAuthn also supports RSA with PKCS1v1.5 padding. 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 the asymmetric cryptographic scheme ECDAA.[35] 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 inherent to this type of curve, which reduces the security guarantees quite substantially. Furthermore, the ECDAA standard involves random, non-deterministic signatures, which already has been a problem in the past.

Paragon Initiative Enterprises also criticized how 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, Paragon Initiative Enterprises still encourage users to continue to use WebAuthn but have come up with some recommendations for potential implementers and developers of the standard that they hope can be implemented before the standard is finalized. Avoiding such mistakes as early as possible would prevent the industry from any challenges that are introduced by broken standards and the need for backwards compatibility.

ECDAA was only designed to be used in combination with device attestation. This particular feature of WebAuthn is not necessarily required for authentication to work. Current implementations allow the user to decide whether an attestation statement is sent during the registration ceremony. Independently, relying parties can choose to require attestation or not. ECDAA was removed from WebAuthn Level 2 as it was not implemented by browsers nor relying parties.[36]

• Web Authentication: An API for accessing Public Key Credentials
• Web Authentication Working Group
• Web Authentication API on MDN
• WebAuthn Awesome