Skip to end of metadata
Go to start of metadata

Previously we showed how single sign-on (Part 1) and two-factor authentication (Part 2) are used to protect web applications. Here we introduce the intriguing (and often misunderstood) notion of passwordless web authentication, which we systematically compare to other web authentication schemes using the semi-structured evaluation framework introduced in Part 1.

Specifically, we compare ordinary password authentication to passwordless web authentication. See the benefits table below for a detailed comparison. See Part 4 for an extended treatment of the relationship between single sign-on and passwordless web authentication.

Contents

Summary

Passwordless web authentication tends to legitimize typical user behavior with respect to memorized secrets. Compared to passwords, the overall usability of passwordless web authentication depends on the type of authenticator in use. In general, the use of biometrics for user verification can improve the usability of passwordless web authentication.

Passwordless web authentication has excellent security and privacy benefits. We show that it provides security benefits well beyond those captured by the original evaluation framework introduced by [Bonneau et al. 2012].

From a deployment perspective, the cost of passwordless web authentication may be significant. More than anything else, this cost will hamper the widespread deployment of the technology. Although the success of passwordless web authentication is far from certain, there are reasons to be hopeful.

References

[Bonneau et al. 2012] Bonneau, Joseph; Herley, Cormac; Oorschot, Paul C. van; Stajano, Frank (2012). “The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes.” University of Cambridge Computer Laboratory, Technical Report Number 817. Cambridge, UK. ISSN 1476-2986.

[NIST 800-63-3 2017] Grassi, Paul A.; Garcia, Michael E.; Fenton, James L. (June 2017). "NIST Special Publication 800-63-3: Digital Identity Guidelines"National Institute of Standards and Technology (NIST). doi:10.6028/NIST.SP.800-63-3.

[W3C WebAuthn Level 1 2019] Balfanz, Dirk; Czeskis, Alexei; Hodges, Jeff; Jones, J.C.; Jones, Michael B.; Kumar, Akshay; Liao, Angelo; Lindemann, Rolf; Lundberg, Emil (eds.). "Web Authentication: An API for accessing Public Key Credentials Level 1 (latest)"World Wide Web Consortium (W3C).

Introducing Multi-Factor Authenticators

Each of the single-factor authentication schemes discussed in Part 2 is intended to be used as a second factor on top of password authentication. In contrast, none of the schemes discussed in this section require a traditional password. In that sense, all of the schemes here are passwordless authentication schemes.

Here we introduce the concept of a multi-factor authenticator (something you have), which is activated by either a PIN (something you know) or a biometric (something you are). A multi-factor authenticator provides multi-factor authentication without layering single-factor authenticators on top of each other.

The ultimate goal of this section is to describe in detail the notion of a FIDO2 authenticator, that is, a multi-factor cryptographic authenticator that is compatible with the W3C Web Authentication (WebAuthn) standard. If the terminology is unfamiliar, please review the concepts introduced in Part 1 and Part 2 of this series.

ATM Card

To withdraw cash from an automated teller machine (ATM), a bank customer inserts an ATM card into a cash machine and types a PIN. The input PIN is compared to the PIN stored on the card’s chip. If the two match, the ATM withdrawal can proceed.

Note that an ATM withdrawal involves a memorized secret (i.e., a PIN) but the true value of the secret is not known to the ATM. The machine blindly passes the input PIN to the card, which compares the customer’s input to the secret PIN stored on the card’s chip. If the two match, the card reports success to the ATM and the transaction continues.

An ATM card is an example of a multi-factor authenticator. The card itself is something you have while the PIN stored on the card’s chip is presumably something you know. Presenting the card to the ATM and demonstrating knowledge of the PIN is a kind of multi-factor authentication.

The ATM checks your account balance in real time but strictly speaking it does not need to be online for authentication purposes since the customer’s PIN need not be transmitted over the network. In fact, the true value of the PIN never leaves the ATM card.

Note that an ATM card does not perform any cryptographic operations. All of the remaining examples in this section are cryptographic authenticators.

Secure Shell

Secure Shell (SSH) is a client-server protocol that uses public-key cryptography to create a secure channel over the network. In contrast to an ATM card, an SSH key is a cryptographic authenticator. The primary authenticator secret is the SSH private key, which is used by the client to digitally sign a message. The corresponding public key is used by the server to verify the message signature, which confirms that the claimant has possession and control of the private key.

To avoid theft, the SSH private key (something you have) may be encrypted using a passphrase (something you know). To initiate a multi-factor authentication process, the claimant supplies the passphrase to the client system.

Like a password, the SSH passphrase is a memorized secret but that’s where the similarity ends. Whereas a password is a shared secret that is transmitted over the network, the SSH passphrase is not shared, and moreover, use of the passphrase is strictly confined to the client system.

Authentication via SSH is an example of passwordless authentication since it avoids the transmission of a shared secret over the network. In fact, SSH authentication does not require a shared secret at all!

FIDO2

The FIDO Universal 2nd Factor (U2F) authentication protocol became the starting point for the FIDO2 Project, a joint effort between the World Wide Web Consortium (W3C) and the FIDO Alliance. Project deliverables include the W3C Web Authentication (WebAuthn) standard and the FIDO Client to Authenticator Protocol (CTAP) specification. Together WebAuthn and CTAP are known as FIDO2, an umbrella term that refers to one (or both) of these technology standards.

A FIDO2 authenticator, also called a WebAuthn authenticator, uses public-key cryptography to interoperate with a WebAuthn client. A type of FIDO2 authenticator called a platform authenticator is tightly integrated into the WebAuthn client platform, that is, it is implemented on the client device itself. A cross-platform authenticator, sometimes called a roaming authenticator, is implemented off the client device. A roaming authenticator connects to the client platform via some transport protocol (such as USB).

A FIDO2 authenticator may be used in either single-factor mode or multi-factor mode. In single-factor mode, the authenticator is activated like any other single-factor authenticator, that is, by a simple test of user presence (e.g., a button push). In multi-factor mode, the authenticator (something you have) is activated by either a PIN (something you know) or a biometric (something you are).

CTAP

The FIDO Client to Authenticator Protocol (CTAP) enables a roaming authenticator (such as a hardware-based security key) to interoperate with a client platform (such as a laptop computer). A roaming authenticator that conforms to CTAP connects to a client via one or more of the following transport bindings: USB, near-field communication (NFC), or Bluetooth Low Energy (BLE).

In the case of a roaming authenticator, CTAP is complementary to WebAuthn. CTAP specifies how a roaming authenticator securely binds WebAuthn API exchanges to a specific transport protocol.

The CTAP specification refers to two protocol versions, the CTAP1/U2F protocol and the CTAP2 protocol. An authenticator that implements the CTAP2 protocol is called a FIDO2 authenticator (also called a WebAuthn authenticator). If that authenticator implements the CTAP1/U2F protocol as well, it is backward compatible with the U2F authentication protocol.

WebAuthn

The W3C Web Authentication (WebAuthn) standard is the centerpiece of the FIDO2 Project. WebAuthn involves a website, a web browser, and an authenticator:

  • The website is a conforming WebAuthn relying party

  • The browser is a conforming WebAuthn client

  • The authenticator is a conforming WebAuthn authenticator (also called a FIDO2 authenticator)

WebAuthn specifies how a claimant demonstrates possession and control of a WebAuthn 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

For the purposes of illustration, we assume the authenticator is a roaming hardware-based authenticator (see below for other options). In any case, the WebAuthn 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, the WebAuthn relying party indicates its intentions to the WebAuthn client (i.e., the browser) via JavaScript. The client communicates with the authenticator using a JavaScript API implemented in the browser.

WebAuthn does not strictly require a roaming hardware-based authenticator. Alternatively, a software-based authenticator (implemented on a smartphone, e.g.) or a platform authenticator (i.e., an authenticator implemented directly on the WebAuthn client device) may be used.

The illustrated flow relies on PIN-based user verification, which, in terms of usability, is competitive with ordinary password authentication. In practice, the use of biometrics for user verification can improve the usability of WebAuthn but there appears to be a lingering misunderstanding among users that biometric data is transmitted over the network in the same manner as passwords, which is not the case.

WebAuthn has all the advantages of Universal 2nd Factor (evaluated in Part 2) but WebAuthn does not require a traditional password. Since no shared secret is transmitted over the network, WebAuthn is sometimes called Passwordless Web Authentication, which is somewhat misleading (due to the PIN). From the deployer’s point of view, however, WebAuthn is passwordless since no shared secrets are stored on the server.

Registration

When the WebAuthn relying party receives the signed authentication assertion from the browser, the digital signature on the assertion is verified using a trusted public key for the claimant. This begs the question: How does the relying party obtain a trusted public key for the user in the first place?

To obtain a public key for the user, the WebAuthn relying party initiates a WebAuthn registration flow that is very similar to the authentication flow illustrated above. The primary difference is that the authenticator now signs an attestation statement with its attestation private key, which is shared by all authenticators of that particular make and model. The signed attestation statement contains a copy of the public key that the WebAuthn relying party ultimately uses to verify a signed authentication assertion. In addition, the attestation statement also contains metadata describing the authenticator itself.

The digital signature on the attestation statement is verified with the trusted attestation public key for that particular model of authenticator. How the WebAuthn relying party obtains its store of trusted attestation public keys is unspecified. One option is to use the FIDO metadata service.

The attestation type requested in the JavaScript determines the trust model. For instance, a type of attestation called self-attestation may be called for, for which the trust model is essentially trust on first use.

Comparing Password and Passwordless

In this section we compare ordinary password authentication to passwordless web authentication using the framework introduced in Part 1. Specifically, we compare the Password and Extended Password single-factor schemes to a pair of multi-factor schemes called Passwordless Off Device and Passwordless On Device. Here the word “passwordless” refers to passwordless web authentication (i.e., WebAuthn) while the word “device” refers to the WebAuthn client device, that is, the device that hosts one or more WebAuthn-compatible web browsers.

Using terminology that was introduced in a previous section, the Passwordless Off Device scheme relies on a roaming authenticator while the Passwordless On Device scheme relies on a platform authenticator.

  • A roaming authenticator is a cross-platform authenticator intended to be used with multiple client devices. A roaming authenticator connects to a client device via USB, near-field communication (NFC), Bluetooth Low Energy (BLE), or some other transport protocol.
  • A platform authenticator is tightly integrated with a particular WebAuthn client device. Using a platform authenticator is nearly indistinguishable from using the device itself.

In the following section, we restrict the features and characteristics of each of the authenticators to allow a reasonable point comparison.

Assumptions

The original Password scheme was introduced by [Bonneau et al. 2012]. The Extended Password scheme assumes that users reuse a single password across all sites. Use of this scheme (in lieu of the original Password scheme) tends to level the playing field with respect to usability, so that significant differences (if any) become readily apparent. See Part 2 for details regarding the Extended Password scheme.

The Passwordless Off Device and Passwordless On Device schemes rely on an authenticator that conforms to the W3C WebAuthn authenticator model. Furthermore, each authenticator is a multi-factor authenticator that is activated by either a PIN or a biometric.

We assume the roaming authenticator is activated by a PIN. The platform authenticator, on the other hand, may be activated by either a PIN or a biometric. This is the most significant difference between the Passwordless Off Device and Passwordless On Device multi-factor authentication schemes.

The Passwordless Off Device multi-factor scheme relies on a roaming authenticator that conforms to the FIDO Client to Authenticator Protocol (known as CTAP2). For simplicity, we assume that both the roaming authenticator and the client device have a compatible USB interface.

The Passwordless On Device multi-factor scheme relies on a platform authenticator. We assume the device platform itself may be unlocked with either a PIN or a biometric. Consequently the platform authenticator is activated using the same PIN or biometric.

Benefits Table

The benefits tables below compare the Password, Extended Password, Passwordless Off Device, and Passwordless On Device authentication schemes.

In the table below, we compare four (4) authentication schemes using the original benefits introduced by [Bonneau et al. 2012] plus the extended benefits defined in Part 1. The Password and Extended Password columns are carried over directly from Part 2. The Passwordless Off Device and Passwordless On Device columns are the result of applying the (extended) framework of [Bonneau et al. 2012]. Justification is given in the sections following this section.



Pass-
word
Ext.
Pass-
word
Pass-
word-
less
Off
Device
Pass-
word-
less
On
Device
U1Memorywise-Effortless
U2Scalable-for-Users
U3Nothing-to-Carry
U4Physically-Effortless


U5Easy-to-Learn
U6Efficient-to-Use
U7Infrequent-Errors
U8Easy-Recovery-from-Loss

D1Accessible
D2Negligible-Cost-per-User

D3Server-Compatible

D4Browser-Compatible
D5Mature

D6Non-Proprietary
D7Negligible-Setup-Cost


D8Negligible-Support-Costs



D9Negligible-Fixed-Cost-per-User

D10Negligible-Variable-Cost-per-Login

S1Resilient-to-Physical-Observation

S2Resilient-to-Targeted-Impersonation
S3Resilient-to-Throttled-Guessing

S4Resilient-to-Unthrottled-Guessing

S5Resilient-to-Internal-Observation


S6Resilient-to-Leaks-from-Other-Verifiers

S7Resilient-to-Phishing

S8Resilient-to-Theft
S9No-Trusted-Third-Party
S10Requiring-Explicit-Consent
S11Unlinkable
S12No-Shared-Secrets-on-the-Server
S13Resilient-to-Verifier-Impersonation



Pass-
word
Ext.
Pass-
word
Pass-
word-
less
Off
Device
Pass-
word-
less
On
Device

Comparison of Password and Passwordless Authentication

⚫= offers the benefit; ⚪= almost offers the benefit; no circle = does not offer the benefit.
U = usability benefit; D = deployability benefit; S = security or privacy benefit.

Portions of the above table are analyzed in the sections below.

Usability Benefits

The following table is an excerpt of the complete benefits table shown above. This abbreviated table compares the Password and Extended Password single-factor schemes with the Passwordless Off Device and Passwordless On Device multi-factor schemes for each of the original eight (8) usability benefits defined by [Bonneau et al. 2012].



Pass-
word
Ext.
Pass-
word
Pass-
word-
less
Off
Device
Pass-
word-
less
On
Device
U1Memorywise-Effortless
U2Scalable-for-Users
U3Nothing-to-Carry
U4Physically-Effortless


U5Easy-to-Learn
U6Efficient-to-Use
U7Infrequent-Errors
U8Easy-Recovery-from-Loss

Comparison of Password and Passwordless Authentication
Usability Benefits

⚫= offers the benefit; ⚪= almost offers the benefit; no circle = does not offer the benefit.

U1. Memorywise-Effortless. The Password single-factor scheme is not Memorywise-Effortless while the Extended Password single-factor scheme is Quasi-Memorywise-Effortless from Part 1. Although both Passwordless schemes require the use of a PIN, a single PIN works with all verifiers and therefore both the Passwordless Off Device and Passwordless On Device multi-factor schemes are Quasi-Memorywise-Effortless.

A platform authenticator does not introduce an additional memorized secret

One is tempted to award the full Memorywise-Effortless benefit to the Passwordless On Device scheme since a platform authenticator does not require an additional memorized secret of its own. However, there is no similar or related example in [Bonneau et al. 2012] so we conservatively award the Quasi-Memorywise-Effortless benefit to the Passwordless On Device scheme.

Users of the scheme do not have to remember any secrets at all. We grant a Quasi-Memorywise-Effortless if users have to remember one secret for everything (as opposed to one per verifier). [Bonneau et al. 2012]

U2. Scalable-for-Users. The Password single-factor scheme is not Scalable-for-Users while the Extended Password single-factor scheme is Scalable-for-Users from Part 1. Both the Passwordless Off Device and Passwordless On Device multi-factor schemes are Scalable-for-Users since the number of accounts does not affect the cognitive load required to use the authenticator.

Using the scheme for hundreds of accounts does not increase the burden on the user. As the mnemonic suggests, we mean “scalable” only from the user’s perspective, looking at the cognitive load, not from a system deployment perspective, looking at allocation of technical resources. [Bonneau et al. 2012]

U3. Nothing-to-Carry. Both the Password and Extended Password single-factor schemes are Nothing-to-Carry from Part 1. The Passwordless Off Device multi-factor scheme clearly lacks the Nothing-to-Carry benefit. The Passwordless On Device multi-factor scheme is fully Nothing-to-Carry since no additional device is required to use a platform authenticator.

Nothing extra to carry

The Nothing-to-Carry benefit should really be called the Nothing-Extra-to-Carry benefit. The authors of the framework clearly intended the latter interpretation.

Users do not need to carry an additional physical object (electronic device, mechanical key, piece of paper) to use the scheme. Quasi-Nothing-to-Carry is awarded if the object is one that they’d carry everywhere all the time anyway, such as their mobile phone, but not if it’s their computer (including tablets). [Bonneau et al. 2012]

U4. Physically-Effortless. The Password single-factor scheme is not Physically-Effortless while the Extended Password single-factor scheme is Quasi-Physically-Effortless from Part 1. The Passwordless Off Device multi-factor scheme is not Physically-Effortless since the user has to fiddle with a separate physical device and then enter a PIN as well. The Passwordless On Device multi-factor scheme is fully Physically-Effortless since there is no device apart from the WebAuthn client device, and moreover, a biometric is the primary means used to activate a platform authenticator.

The authentication process does not require physical (as opposed to cognitive) user effort beyond, say, pressing a button. Schemes that don’t offer this benefit include those that require typing, scribbling or performing a set of motions. We grant Quasi-Physically-Effortless if the user’s effort is limited to speaking, on the basis that even illiterate people find that natural to do. [Bonneau et al. 2012]

U5. Easy-to-Learn. Both the Password and Extended Password single-factor schemes are Easy-to-Learn from Part 1. Both of the Passwordless multi-factor schemes are Easy-to-Learn since the use of a PIN or a biometric are well established user operations.

The roaming authenticator has a USB interface

We assume the roaming authenticator has a USB interface so as not to introduce a learning curve. The use of some other transport protocol (such as near-field communication or Bluetooth Low Energy) may cause the Passwordless Off Device scheme to lose the Easy-to-Learn benefit.

Users who don’t know the scheme can figure it out and learn it without too much trouble, and then easily recall how to use it. [Bonneau et al. 2012]

U6. Efficient-to-Use. Both the Password and Extended Password single-factor schemes are Efficient-to-Use from Part 1. The time required to type a PIN is no more (and probably less) than the time to type a shared secret, and so the Passwordless Off Device multi-factor scheme is Efficient-to-Use since the original Password scheme is deemed to be Efficient-to-Use by the framework. The Passwordless On Device multi-factor scheme is Efficient-to-Use since using a biometric is more efficient than using a PIN.

The time the user must spend for each authentication is acceptably short. The time required for setting up a new association with a verifier, although possibly longer than that for authentication, is also reasonable. [Bonneau et al. 2012]

U7. Infrequent-Errors. The Password single-factor scheme is Quasi-Infrequent-Errors while the Extended Password single-factor scheme is fully Infrequent-Errors from Part 1. Since a PIN is presumably simpler than a shared secret, typing a PIN is less error-prone than typing a shared secret, and therefore the Passwordless Off Device multi-factor scheme has Infrequent-Errors. Using a biometric may be more error-prone than using a PIN, and so the Passwordless On Device multi-factor scheme is conservatively rated Quasi-Infrequent-Errors to emphasize that this benefit is implementation-dependent.

Biometrics are inherently error-prone

All biometrics tend to be error-prone but a solid implementation will minimize the frequency of error.

The task that users must perform to log in usually succeeds when performed by a legitimate and honest user. In other words, the scheme isn’t so hard to use or unreliable that genuine users are routinely rejected. [Bonneau et al. 2012]

U8. Easy-Recovery-from-Loss. Both the Password and Extended Password single-factor schemes are Easy-Recovery-from-Loss from Part 1. Neither of the Passwordless multi-factor schemes are Easy-Recovery-from-Loss.

A user can conveniently regain the ability to authenticate if the token is lost or the credentials forgotten. This combines usability aspects such as: low latency before restored ability; low user inconvenience in recovery (e.g., no requirement for physically standing in line); and assurance that recovery will be possible, for example via built-in backups or secondary recovery schemes. If recovery requires some form of re-enrollment, this benefit rates its convenience. [Bonneau et al. 2012]

Discussion

As is well known, the Password scheme is neither Memorywise-Effortless nor Scalable-for-Users. Assuming users reuse a single password across all websites, the Extended Password scheme becomes Quasi-Memorywise-Effortless and Scalable-for-Users. Similarly, since a single PIN works for all verifiers, both of the Passwordless multi-factor schemes are likewise Quasi-Memorywise-Effortless and Scalable-for-Users. From this we conclude that passwordless web authentication tends to legitimize typical user behavior with respect to memorized secrets.

The Usability of Platform Authenticators

The results of the comparison beg the question: Is passwordless web authentication more or less usable than password authentication? The analysis clearly shows that the answer depends on the type of authenticator. A roaming authenticator is less usable than a password even if you assume the user reuses a single password across all websites. Most importantly, the Passwordless Off Device scheme lacks the Nothing-to-Carry benefit, a seemingly inherent quality of every roaming authenticator. See below for further discussion along these lines.

Ignoring the Easy-Recovery-from-Loss benefit (which is lacking in most, if not all something you have authenticators), a platform authenticator is more usable than a password. Not only does it win back the Nothing-to-Carry benefit but the Passwordless On Device scheme is awarded the Physically-Effortless benefit as well. This is a remarkable achievement for an authenticator that is something you have.

In summary, the usability of the Passwordless Off Device scheme is lacking in certain aspects while the overall usability of the Passwordless On Device scheme is excellent. In the following subsection, we show how the use of biometrics for user verification can significantly improve the usability of passwordless web authentication, but possibly at the expense of other benefits.

The Importance of Biometrics

The Passwordless Off Device scheme relies on PIN-based user verification, which is found to be both Quasi-Memorywise-Effortless and fully Infrequent-Errors but not Physically-Effortless. If we introduce biometric user verification to a roaming authenticator, does any of this change? More generally, what are the usability characteristics of any multi-factor authenticator, with or without biometric user verification?

In principle, an authenticator that is activated by a biometric is fully Memorywise-Effortless but it is unlikely that a biometric authenticator would possess the full Infrequent-Errors benefit. Experience has shown that using biometrics for user verification require a fallback verification mechanism. That fallback is almost certainly a PIN, in which case we’re back to Quasi-Memorywise-Effortless, which appears to be the lowest common denominator for multi-factor authenticators, with or without biometrics.

Unlike PIN-based user verification, an authenticator that is activated by a biometric is at least Quasi-Physically-Effortless and may be fully Physically-Effortless depending on the implementation. For example, Apple Touch ID, which was introduced in 2013, requires no more effort than a button push, and so an authenticator equipped with a fingerprint reader that is at least as good as Touch ID would be awarded the full Physically-Effortless benefit.

OTOH, biometrics may have deployability, security, and privacy concerns. Is the biometric Accessible? Can the biometric be spoofed or leaked? With respect to leakage, it is worth noting that a biometric wholly contained on a roaming authenticator could very well have privacy advantages. This scheme is not rated here since roaming authenticators with integrated biometrics are not yet mainstream.

In summary, a multi-factor authenticator with biometric user verification and PIN backup is Quasi-Memorywise-Effortless, at least Quasi-Infrequent-Errors, and at least Quasi-Physically-Effortless. The latter two benefits are implementation-dependent, which suggests that highly usable multi-factor authenticators will be distinguished based on their biometric capability. Whether or not they exhibit the desired deployability, security, and privacy benefits must be evaluated on a case-by-case basis.

Avoiding an Extra Carry

There are at least three ways to avoid an extra carry:

  1. Use a platform authenticator (such as the Passwordless On Device scheme above)
  2. Use an authenticator that fits entirely inside a USB port (such as the YubiKey 5 Nano)
  3. Use a phone-based roaming authenticator

In this section, we focus on the latter.

A roaming authenticator that conforms to the FIDO Client to Authenticator Protocol (CTAP) usually takes the form of a dedicated USB device but other form factors and transport protocols are possible. Consider, for example, a roaming authenticator with a Bluetooth interface. Such an authenticator could be integrated into a device that already has a Bluetooth interface, such as a smartphone. In this case, the smartphone functions as an authenticator for any WebAuthn client device with a Bluetooth interface.

Since most people tend to carry their mobile phones wherever they go, a phone-based authenticator avoids an extra carry, at least partially. Indeed, the framework of [Bonneau et al. 2012] awards the Quasi-Nothing-to-Carry benefit to any phone-based authentication scheme.

On the downside, the use of a phone-based roaming authenticator with a Bluetooth interface might have a negative effect on other usability benefits such as Physically-Effortless or Easy-to-Learn. Like other phone-based authenticators, a roaming authenticator integrated into a smartphone may also lack some important security benefits. Each implementation must be evaluated based on its merits.

You can hold an authenticator (such as a smartphone) in your hand or you can wear an authenticator on your face, wrist, or finger. Wearable roaming authenticators that conform to CTAP include smartwatches and rings. An interesting concrete example is the Token ring, which remains activated for as long as it’s on your finger. In this case we get the second biometric factor almost for free.

Recovering from Loss

Note that both of the Passwordless multi-factor schemes lack the Easy-Recovery-from-Loss benefit. This is a significant liability. A passwordless recovery mechanism that approaches Easy-Recovery-from-Loss remains an essential missing ingredient.

Deployability Benefits

The following table is an excerpt of the complete benefits table shown above. This abbreviated table compares the Password and Extended Password single-factor schemes with the Passwordless Off Device and Passwordless On Device multi-factor schemes for each of the original six (6) deployability benefits defined by [Bonneau et al. 2012] plus four extended benefits (D7D10).



Pass-
word
Ext.
Pass-
word
Pass-
word-
less
Off
Device
Pass-
word-
less
On
Device
D1Accessible
D2Negligible-Cost-per-User

D3Server-Compatible

D4Browser-Compatible
D5Mature

D6Non-Proprietary
D7Negligible-Setup-Cost


D8Negligible-Support-Costs



D9Negligible-Fixed-Cost-per-User

D10Negligible-Variable-Cost-per-Login

Comparison of Password and Passwordless Authentication
Deployability Benefits

⚫= offers the benefit; ⚪= almost offers the benefit; no circle = does not offer the benefit.

D1. Accessible. Both the Password and Extended Password schemes are Accessible from Part 1. The Passwordless Off Device multi-factor scheme is Accessible since typing a PIN is no worse than typing a password whereas the latter is deemed to be Accessible by the framework. Using a biometric may or may not be accessible, and so the Passwordless On Device multi-factor scheme is conservatively rated Quasi-Accessible to emphasize that this benefit is implementation-dependent.

Is a biometric accessible?

An authenticator that is activated by a biometric may or may not be Accessible. Since biometrics are commonly used on various devices, we expect most accessibility issues to already be addressed but each implementation will require its own assessment.

Users who can use passwords are not prevented from using the scheme by disabilities or other physical (not cognitive) conditions. [Bonneau et al. 2012]

D2. Negligible-Cost-per-User. Both the Password and Extended Password schemes have Negligible-Cost-per-User from Part 1. Neither of the Passwordless multi-factor schemes has Negligible-Cost-per-User since there are significant setup costs on the server. Compare with D3, which is a related benefit.

Deployment costs

The Passwordless Off Device scheme has a significant fixed cost per-user in addition to its setup cost. See extended benefits D7D10 for additional cost information.

The total cost per user of the scheme, adding up the costs at both the prover’s end (any devices required) and the verifier’s end (any share of the equipment and software required), is negligible. The scheme is plausible for startups with no per-user revenue. [Bonneau et al. 2012]

D3. Server-Compatible. Both the Password and Extended Password schemes are Server-Compatible from Part 1. Neither of the Passwordless multi-factor schemes are Server-Compatible since the verifier must implement the requirements of the WebAuthn standard. Compare with D2, which is a related benefit.

At the verifier’s end, the scheme is compatible with text-based passwords. Providers don’t have to change their existing authentication setup to support the scheme. [Bonneau et al. 2012]

D4. Browser-Compatible. Both the Password and Extended Password schemes are Browser-Compatible from Part 1. Since the browser vendors are well on their way towards a full implementation of the WebAuthn standard, we choose to award the Browser-Compatible benefit to both of the Passwordless multi-factor schemes.

Users don’t have to change their client to support the scheme and can expect the scheme to work when using other machines with an up-to-date, standards-compliant web browser and no additional software. In 2012, this would mean an HTML5-compliant browser with JavaScript enabled. Schemes fail to provide this benefit if they require the installation of plugins or any kind of software whose installation requires administrative rights. Schemes offer Quasi-Browser-Compatible if they rely on nonstandard but very common plugins, e.g., Flash. [Bonneau et al. 2012]

D5. Mature. Both the Password and Extended Password schemes are Mature from Part 1. Neither of the Passwordless multi-factor schemes are Mature since deployments of the relevant standards are still scarce. In particular, WebAuthn relying party deployments are almost nonexistent.

The scheme has been implemented and deployed on a large scale for actual authentication purposes beyond research. Indicators to consider for granting the full benefit may also include whether the scheme has undergone user testing, whether the standards community has published related documents, whether open-source projects implementing the scheme exist, whether anyone other than the implementers has adopted the scheme, the amount of literature on the scheme and so forth. [Bonneau et al. 2012]

D6. Non-Proprietary. Both the Password and Extended Password schemes are Non-Proprietary from Part 1. Since both the CTAP specification and the WebAuthn specification are open standards, both of the Passwordless multi-factor schemes are Non-Proprietary as well.

Anyone can implement or use the scheme for any purpose without having to pay royalties to anyone else. The relevant techniques are generally known, published openly and not protected by patents or trade secrets. [Bonneau et al. 2012]

D7. Negligible-Setup-Cost. Both the Password and Extended Password schemes have Negligible-Setup-Cost from Part 1. Neither of the Passwordless multi-factor schemes have Negligible-Setup-Cost, which is reflected in D2 as well.

D8. Negligible-Support-Costs. Neither the Password scheme nor the Extended Password scheme have Negligible-Support-Costs from Part 1. The Passwordless Off Device multi-factor scheme is believed not to have Negligible-Support-Costs. The Passwordless On Device multi-factor scheme is deemed to have Quasi-Negligible-Support-Costs since there is no additional device or process that requires specialized support.

D9. Negligible-Fixed-Cost-per-User. Both the Password and Extended Password schemes have Negligible-Fixed-Cost-per-User from Part 1. The Passwordless Off Device multi-factor scheme does not have Negligible-Fixed-Cost-per-User since a roaming authenticator is itself an additional device. The Passwordless On Device multi-factor scheme has Negligible-Fixed-Cost-per-User since no additional device is required to use a platform authenticator.

D10. Negligible-Variable-Cost-per-Login. Both the Password and Extended Password schemes have Negligible-Variable-Cost-per-Login from Part 1. Both of the Passwordless multi-factor schemes have Negligible-Variable-Cost-per-Login as well.

Discussion

The FIDO Universal 2nd Factor (U2F) protocol specification was formally submitted to the World Wide Web Consortium (W3C) on November 12, 2015. Using U2F as a starting point, the first draft of the W3C Web Authentication (WebAuthn) specification was published six months later. By the time the draft became a W3C Recommendation on March 4, 2019, the WebAuthn JavaScript API had already been implemented (to varying degrees) in Microsoft Edge, Google Chrome, Mozilla Firefox, and Opera. Apple Safari started to implement WebAuthn in December 2018.

Since all of the browser vendors are actively moving towards a full implementation of the WebAuthn standard, we choose to award the full Browser-Compatible benefit to both of the Passwordless multi-factor schemes. This generous rating reflects the unprecedented cooperation of the browser vendors in this space.

Cost Analysis

Neither of the Passwordless multi-factor schemes are Server-Compatible since the verifier must implement the requirements of the WebAuthn standard. Specifically, the verifier must become a WebAuthn relying party by implementing and deploying a public-key infrastructure, which is no small task. Consequently neither scheme has Negligible-Cost-per-User since the latter benefit includes significant setup costs on the server.

The Negligible-Cost-per-User benefit does not tell the whole story, however. The Passwordless Off Device scheme requires an extra carry while the Passwordless On Device scheme does not. Depending on the number of users, this hardware cost could be significant in its own right.

In summary, neither of the Passwordless schemes have Negligible-Setup-Cost but the Passwordless On Device scheme does have Negligible-Fixed-Cost-per-User, a benefit that the Passwordless Off Device scheme does not have. Clearly the Passwordless On Device scheme has an overall cost advantage.

Security and Privacy Benefits

The following table is an excerpt of the complete benefits table shown above. This abbreviated table compares the Password and Extended Password single-factor schemes with the Passwordless Off Device and Passwordless On Device multi-factor schemes for each of the original eleven (11) security and privacy benefits defined by [Bonneau et al. 2012] plus two extended benefits (S12S13).



Pass-
word
Ext.
Pass-
word
Pass-
word-
less
Off
Device
Pass-
word-
less
On
Device
S1Resilient-to-Physical-Observation

S2Resilient-to-Targeted-Impersonation
S3Resilient-to-Throttled-Guessing

S4Resilient-to-Unthrottled-Guessing

S5Resilient-to-Internal-Observation


S6Resilient-to-Leaks-from-Other-Verifiers

S7Resilient-to-Phishing

S8Resilient-to-Theft
S9No-Trusted-Third-Party
S10Requiring-Explicit-Consent
S11Unlinkable
S12No-Shared-Secrets-on-the-Server
S13Resilient-to-Verifier-Impersonation

Comparison of Password and Passwordless Authentication
Security and Privacy Benefits

⚫= offers the benefit; ⚪= almost offers the benefit; no circle = does not offer the benefit.

S1. Resilient-to-Physical-Observation. Neither the Password scheme nor the Extended Password scheme is Resilient-to-Physical-Observation from Part 1. Both of the Passwordless multi-factor schemes are Resilient-to-Physical-Observation. The Passwordless Off Device scheme is Resilient-to-Physical-Observation since an attacker that obtains knowledge of the PIN (by whatever means) must also obtain the hardware-based authenticator itself. The Passwordless On Device scheme is Resilient-to-Physical-Observation since an attacker that possesses sufficient biometric data to impersonate the user must also obtain the WebAuthn client device.

An attacker cannot impersonate a user after observing them authenticate one or more times. We grant Quasi-Resilient-to-Physical-Observation if the scheme could be broken only by repeating the observation more than, say, 10–20 times. Attacks include shoulder surfing, filming the keyboard, recording keystroke sounds, or thermal imaging of keypad. [Bonneau et al. 2012]

S2. Resilient-to-Targeted-Impersonation. Both the Password and Extended Password schemes are Quasi-Resilient-to-Targeted-Impersonation from Part 1. Both of the Passwordless multi-factor schemes are Resilient-to-Targeted-Impersonation for the same reason they are Resilient-to-Physical-Observation: the attacker must also obtain a physical device (something you have) to impersonate the user.

It is not possible for an acquaintance (or skilled investigator) to impersonate a specific user by exploiting knowledge of personal details (birth date, names of relatives etc.). Personal knowledge questions are the canonical scheme that fails on this point. [Bonneau et al. 2012]

S3. Resilient-to-Throttled-Guessing. Neither the Password scheme nor the Extended Password scheme is Resilient-to-Throttled-Guessing from Part 1. Both of the Passwordless multi-factor schemes are Resilient-to-Throttled-Guessing for the same reason they are Resilient-to-Physical-Observation: the attacker must also obtain a physical device (something you have) to impersonate the user.

An attacker whose rate of guessing is constrained by the verifier cannot successfully guess the secrets of a significant fraction of users. The verifier-imposed constraint might be enforced by an online server, a tamper-resistant chip or any other mechanism capable of throttling repeated requests. To give a quantitative example, we might grant this benefit if an attacker constrained to, say, 10 guesses per account per day, could compromise at most 1% of accounts in a year. Lack of this benefit is meant to penalize schemes in which it is frequent for user-chosen secrets to be selected from a small and well-known subset (low min-entropy). [Bonneau et al. 2012]

S4. Resilient-to-Unthrottled-Guessing. Neither the Password scheme nor the Extended Password scheme is Resilient-to-Unthrottled-Guessing from Part 1. Both of the Passwordless multi-factor schemes are Resilient-to-Unthrottled-Guessing for the same reason they are Resilient-to-Physical-Observation: the attacker must also obtain a physical device (something you have) to impersonate the user.

An attacker whose rate of guessing is constrained only by available computing resources cannot successfully guess the secrets of a significant fraction of users. We might for example grant this benefit if an attacker capable of attempting up to 2 40 or even 2 64 guesses per account could still only reach fewer than 1% of accounts. Lack of this benefit is meant to penalize schemes where the space of credentials is not large enough to withstand brute force search (including dictionary attacks, rainbow tables and related brute force methods smarter than raw exhaustive search, if credentials are user-chosen secrets). [Bonneau et al. 2012]

S5. Resilient-to-Internal-Observation. Neither the Password scheme nor the Extended Password scheme are Resilient-to-Internal-Observation from Part 1. The Passwordless Off Device multi-factor scheme is Resilient-to-Internal-Observation for the same reason it is Resilient-to-Physical-Observation: even if malware intercepts the PIN, the attacker must also obtain the hardware-based authenticator to impersonate the user. The Passwordless On Device scheme is not Resilient-to-Internal-Observation since malware on the client device can interfere with the operation of the platform authenticator.

An attacker cannot impersonate a user by intercepting the user’s input from inside the user’s device (e.g., by key-logging malware) or eavesdropping on the cleartext communication between prover and verifier (we assume that the attacker can also defeat TLS if it is used, perhaps through the CA). As with Resilient-to-Physical-Observation above, we grant Quasi-Resilient-to-Internal-Observation if the scheme could be broken only by intercepting input or eavesdropping cleartext more than, say, 10–20 times. This penalizes schemes that are not replay-resistant, whether because they send a static response or because their dynamic response countermeasure can be cracked with a few observations. This benefit assumes that general-purpose devices like software-updatable personal computers and mobile phones may contain malware, but that hardware devices dedicated exclusively to the scheme can be made malware-free. We grant Quasi-Resilient-to-Internal-Observation to two-factor schemes where both factors must be malware-infected for the attack to work. If infecting only one factor breaks the scheme, we don’t grant the benefit. [Bonneau et al. 2012]

S6. Resilient-to-Leaks-from-Other-Verifiers. Neither the Password scheme nor the Extended Password scheme is Resilient-to-Leaks-from-Other-Verifiers from Part 1. Both of the Passwordless multi-factor schemes are Resilient-to-Leaks-from-Other-Verifiers since there is nothing a verifier could leak that would help an attacker impersonate the user to another verifier.

Nothing that a verifier could possibly leak can help an attacker impersonate the user to another verifier. This penalizes schemes where insider fraud at one provider, or a successful attack on one backend, endangers the user’s accounts at other sites. [Bonneau et al. 2012]

S7. Resilient-to-Phishing. Neither the Password scheme nor the Extended Password scheme are Resilient-to-Phishing from Part 1. Both of the Passwordless multi-factor schemes are Resilient-to-Phishing since there is nothing in the authentication assertion payload that an attacker can leverage to subsequently impersonate the user.

The Passwordless schemes are resilient to verifier impersonation

Both of the Passwordless multi-factor schemes are also resistant to an active man-in-the-middle (which the Resilient-to-Phishing benefit intentionally ignores). In other words, the Passwordless schemes are Resilient-to-Verifier-Impersonation. See extended benefit S13 for details.

An attacker who simulates a valid verifier (including by DNS manipulation) cannot collect credentials that can later be used to impersonate the user to the actual verifier. This penalizes schemes allowing phishers to get victims to authenticate to lookalike sites and later use the harvested credentials against the genuine sites. It is not meant to penalize schemes vulnerable to more sophisticated real-time man-in-the-middle or relay attacks, in which the attackers have one connection to the victim prover (pretending to be the verifier) and simultaneously another connection to the victim verifier (pretending to be the prover). [Bonneau et al. 2012]

S8. Resilient-to-Theft. Both the Password and Extended Password schemes are Resilient-to-Theft from Part 1. Both of the Passwordless multi-factor schemes are at least Quasi-Resilient-to-Theft since user verification is required to activate the authenticator. An implementation may be fully Resilient-to-Theft if verification attempts are sufficiently rate-controlled.

A multi-factor authenticator is inherently resilient to theft

This benefit illustrates one reason why a multi-factor authenticator is preferred—a single-factor authenticator (such as a U2F authenticator) is not Resilient-to-Theft.

If the scheme uses a physical object for authentication, the object cannot be used for authentication by another person who gains possession of it. We still grant Quasi-Resilient-to-Theft if the protection is achieved with the modest strength of a PIN, even if attempts are not rate-controlled, because the attack doesn’t easily scale to many victims. [Bonneau et al. 2012]

S9. No-Trusted-Third-Party. Both the Password and Extended Password schemes are No-Trusted-Third-Party from Part 1. The Passwordless Off Device scheme is not No-Trusted-Third-Party since the manufacturer of the roaming authenticator must be trusted. The Passwordless On Device scheme is No-Trusted-Third-Party since the platform (and therefore the platform authenticator) is already trusted by the framework.

The device platform is trusted

The framework [Bonneau et al. 2012] implicitly assumes the platform is trusted, otherwise authentication is a non-starter.

The scheme does not rely on a trusted third party (other than the prover and the verifier) who could, upon being attacked or otherwise becoming untrustworthy, compromise the prover’s security or privacy. [Bonneau et al. 2012]

S10. Requiring-Explicit-Consent. Both the Password and Extended Password schemes are Requiring-Explicit-Consent from Part 1. Both of the Passwordless multi-factor schemes are Requiring-Explicit-Consent since user verification is required to activate the authenticator.

The authentication process cannot be started without the explicit consent of the user. This is both a security and a privacy feature (a rogue wireless RFID-based credit card reader embedded in a sofa might charge a card without user knowledge or consent). [Bonneau et al. 2012]

S11. Unlinkable. Both the Password and Extended Password schemes are Unlinkable from Part 1. Both of the Passwordless multi-factor schemes are Unlinkable since the authenticator creates a new key pair for each WebAuthn relying party.

Colluding verifiers cannot determine, from the authenticator alone, whether the same user is authenticating to both. This is a privacy feature. To rate this benefit we disregard linkability introduced by other mechanisms (same user ID, same IP address, etc). [Bonneau et al. 2012]

S12. No-Shared-Secrets-on-the-Server. Both the Password and Extended Password schemes are Quasi-No-Shared-Secrets-on-the-Server from Part 1. Both Passwordless multi-factor schemes have No-Shared-Secrets-on-the-Server since only public keys are stored on the server.

S13. Resilient-to-Verifier-Impersonation. Neither the Password scheme nor the Extended Password scheme are Resilient-to-Verifier-Impersonation from Part 1. Both Passwordless multi-factor schemes are Resilient-to-Verifier-Impersonation by virtue of the WebAuthn protocol.

Discussion

Overall the Passwordless multi-factor schemes have very strong security and privacy properties. In particular, passwordless web authentication (WebAuthn) provides both of the extended security benefits No-Shared-Secrets-on-the-Server and Resilient-to-Verifier-Impersonation.

Despite these strengths, one or both of the Passwordless schemes have the following shortcomings:

  • The Passwordless On Device scheme is not Resilient-to-Internal-Observation
  • The Passwordless Off Device scheme is not No-Trusted-Third-Party
  • Both schemes are only Quasi-Resilient-to-Theft

See the following subsections for further discussion of these topics.

Malware

Some of the security properties of the Passwordless Off Device scheme are a consequence of the hardware-based roaming authenticator, at least in part. What happens if we relax this assumption?

The Passwordless Off Device scheme rated above is fully Resilient-to-Internal-Observation by virtue of the hardware-based roaming authenticator. In general, a roaming authenticator (hardware or software) is at least Quasi-Resilient-to-Internal-Observation since both the authenticator and the WebAuthn client device must be infected with malware for an attack to succeed. In any case, since the framework assumes that a hardware-based authenticator is malware-free, the Passwordless Off Device scheme as defined is fully Resilient-to-Internal-Observation.

OTOH, a platform authenticator may not be Resilient-to-Internal-Observation if the platform itself is sufficiently vulnerable to malware. To be awarded this benefit, a platform authenticator must demonstrate its ability to resist malware. For this reason, the Passwordless On Device scheme is not awarded the Resilient-to-Internal-Observation benefit.

Authenticator Loss or Theft

Both of the Passwordless multi-factor schemes are at least Quasi-Resilient-to-Theft since user verification is required to activate the authenticator. This is true of all multi-factor authenticators by definition. In contrast, a single-factor authenticator is inherently not Resilient-to-Theft. For example, the Password + FIDO U2F two-factor authentication scheme is Resilient-to-Theft by virtue of the password even though the U2F authenticator itself is not Resilient-to-Theft. See Part 2 for more information.

The Passwordless Off Device multi-factor scheme is Quasi-Resilient-to-Theft since a roaming authenticator that conforms to CTAP has a PIN, and presumably that PIN provides some measure of protection if the hardware-based authenticator is lost or stolen. An implementation may be fully Resilient-to-Theft if verification attempts are sufficiently rate-controlled.

The Passwordless On Device multi-factor scheme relies on a platform authenticator, which itself relies on the platform. Let’s suppose the device platform may be unlocked with either a PIN or a biometric. Consequently the platform authenticator may be activated using the same PIN or biometric. In this case, the Passwordless On Device multi-factor scheme earns the Quasi-Resilient-to-Theft benefit by virtue of the platform. Note that the platform authenticator is protected from unauthorized use even if the client device is permanently unlocked.

Extended Security Benefits

The Passwordless multi-factor schemes are both No-Shared-Secrets-on-the-Server and Resilient-to-Verifier-Impersonation while neither of the Password schemes have these benefits. The Passwordless schemes are Resilient-to-Verifier-Impersonation by virtue of the WebAuthn protocol. With the help of a WebAuthn client, a WebAuthn authenticator associates a new key pair with the origin of the WebAuthn relying party (i.e., the verifier). Subsequent use of that key pair requires a matching origin.

Reliance on Third Parties

The Passwordless Off Device scheme is not No-Trusted-Third-Party since the hardware authenticator is manufactured by a third party. This is not an inherent limitation, however. An open-source authenticator (such as the open-source Solo from SoloKeys) may be awarded the full No-Trusted-Third-Party benefit.

Related to this, the FIDO Alliance has taken two important steps to facilitate trust within the community:

  1. The FIDO certification program
  2. The FIDO metadata service

The FIDO certification program validates a product’s conformance to FIDO standards as well as its interoperability with other FIDO-certified products. This includes both roaming and platform authenticators, which may become FIDO-certified in terms of compatibility and security. Note that the biometric components of authenticators may be independently tested and certified. Such is the case with the Samsung Galaxy S10 and S10+ smartphones.

The FIDO metadata service is a trusted, centralized source of information about FIDO authenticators. A digitally signed metadata file contains a list of authenticators along with their trusted attestation public keys. When a new authenticator is introduced in the marketplace, its metadata is added to the list. As vulnerabilities are discovered in existing authenticators, the corresponding metadata is removed from the list.

  • No labels