Skip to end of metadata
Go to start of metadata

Apart from single sign-on (Part 1), the best thing you can do to protect a web application is to use two-factor authentication. One approach is to layer a second authentication factor on top of password authentication. Since a password is something you know, that second factor is usually something you have. Due to privacy concerns, biometrics (something you are) are seldom used for web authentication, but see Part 3 for a glimpse of things to come.

There are two ways to achieve multi-factor authentication: either 1) use a multi-factor authenticator, or 2) use a combination of two or more single-factor authenticators. This article describes a handful of single-factor authenticators and shows how to combine them to achieve multi-factor authentication. See Part 3 for an introduction to multi-factor authenticators.

Contents

Summary

Overall the three non-password schemes (OATH OTP, Mobile Push, and FIDO U2F) exhibit significantly better security than the password schemes (which is expected). However, by themselves, none of the non-password schemes are Resilient-to-Theft. Also note that only one of the non-password schemes (OATH OTP) has the No-Trusted-Third-Party benefit. Finally, it is an important fact that only one of the schemes (FIDO U2F) is Resilient-to-Verifier-Impersonation.

In terms of usability, the non-password schemes are competitive with the password schemes although one of the non-password schemes (OATH OTP) has some notable weaknesses. In any case, none of the non-password schemes are fully Nothing-to-Carry, and moreover, none of the non-password schemes are even Quasi-Easy-Recovery-from-Loss.

In terms of deployability, all of the non-password schemes have significant drawbacks (as expected). In particular, none of the non-password schemes are Server-Compatible, Negligible-Setup-Cost, or Negligible-Cost-per-User (specifically Negligible-Fixed-Cost-per-User).

In general, a two-factor scheme inherits its characteristics from the corresponding single-factor schemes. In terms of usability and deployability, a two-factor scheme is as strong as its weakest factor. In terms of security, a two-factor scheme is as strong as its strongest factor. See the benefits table below for details about combined single-factor schemes.

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.

Introducing Single-Factor Authenticators

By definition, an authenticator is used to perform digital authentication. A person authenticates to a computer system or application by demonstrating that he or she has possession and control of an authenticator. In the simplest case, the authenticator is a common password.

Using the terminology of the NIST Digital Identity Guidelines, the party to be authenticated is called the claimant while the party verifying the identity of the claimant is called the verifier. When the claimant successfully demonstrates possession and control of one or more authenticators to the verifier through an established authentication protocol, the verifier is able to infer the claimant’s identity.

An authenticator is associated with at least one secret that the claimant can use to demonstrate possession and control of the authenticator. Since an attacker could use this secret to impersonate the user, an authenticator secret must be protected from theft or loss.

The following subsections briefly illustrate a number of different types of single-factor authenticators, from the oldest (password) to the most recent (Universal 2nd Factor).

Password

Password AuthenticationThe common password is a trivial example of an authenticator. A password is something you know while the authenticator secret is the password itself.

A password is intended to be memorized by the claimant and shared with the verifier. Password authentication is a process whereby the claimant demonstrates knowledge of the password by transmitting it over the network to the verifier. If the transmitted password agrees with the previously shared secret, user authentication is successful.

Sharing a secret (such as a password) with a verifier is risky since the verifier may lose control of the secret. Transmitting a password over the network represents an additional risk. Despite these risks, passwords have been in use since the early 1960s.

If a claimant shares the same password with multiple verifiers, a compromise at one verifier spills over to other verifiers. To prevent this, for a given user, every verifier should have a unique password, which puts a significant burden on the password owner.

OATH OTP

A traditional password (something you know) is often combined with a one-time password (something you have) to provide two-factor authentication. Both the password and the one-time password (OTP) are transmitted over the network to the verifier. If the password agrees with the previously shared secret, and the verifier can confirm the value of the OTP, user authentication is successful.

There are at least two types of OTP authenticators: OTP over SMS (i.e., text message) and OTP generated by a cryptographic method. The rest of this section focuses on the latter. For more information about OTP over SMS, see section IV-I4 in [Bonneau et al. 2012].

One-time passwords (OTPs) have been used since the 1980s. An initial reference architecture for secure generation of OTPs was published by the Initiative for Open Authentication (OATH) in 2004. Two IETF standards grew out of this work: OATH HOTP and OATH TOTP. By OATH OTP, we mean either OATH HOTP or OATH TOTP.

One-time passwords (OTPs) are generated on demand by a dedicated OTP authenticator that encapsulates a secret that is shared with the verifier. Using the authenticator, the claimant generates an OTP using a cryptographic method. The verifier also generates an OTP using the same cryptographic method. If the two OTP values match, the verifier can conclude that the claimant possesses the shared secret.

Transmitting both the password and the one-time password over the network mitigates the risk of transmitting the password alone. However, the use of one-time passwords introduces a new risk since the verifier must manage yet another shared secret.

Mobile Push

A mobile push authenticator is essentially a native app running on the claimant’s mobile phone. The app uses public-key cryptography to respond to push notifications. In other words, a mobile push authenticator is an example of a cryptographic software authenticator.

A mobile push authenticator (something you have) is usually combined with a password (something you know) to provide two-factor authentication. Unlike one-time passwords, mobile push does not require a shared secret beyond the password.

A mobile push authenticator is an example of an out-of-band authenticator since the mobile push authentication protocol runs on an independent second channel. After the claimant authenticates with a password, the verifier makes a back-channel authentication request to a trusted third party that manages a public-key infrastructure (PKI) on behalf of the verifier. The trusted third party sends a push notification to the claimant’s mobile phone. The claimant demonstrates possession and control of the authenticator by performing a test of user presence (TUP), after which the authenticator responds with a digitally signed assertion. The trusted third party verifies the signature on the assertion and returns an authentication response to the verifier.

To activate a mobile push authenticator, the claimant is required to perform a TUP, which consists of a simple button push. A TUP helps prevent unauthorized access to the authenticator’s functionality. For additional protection, the user interface on the mobile phone may present detailed information about the transaction (such as the IP address and corresponding geographical location of the device that transmitted the password to the verifier). This helps prevent active man-in-the-middle attacks.

The public-key infrastructure (PKI) is usually outsourced to a trusted third party, which provides flexible deployment options. OTOH, since the mobile push authentication protocol requires an open network path to the claimant’s mobile phone, if no such path is available (due to network issues, e.g.), the authentication process can not proceed.

FIDO U2F

The initial version of the Universal 2nd Factor (U2F) authentication protocol was published in 2014 by the FIDO Alliance. On September 4, 2015, the specification documents were formally submitted to the World Wide Web Consortium (W3C). These documents eventually became the W3C Web Authentication (WebAuthn) standard (see Part 3 for details).

A U2F authenticator is a single-factor cryptographic authenticator intended to be used in conjunction with an ordinary web password. Since the authenticator relies on public-key cryptography, U2F does not require an additional shared secret beyond the password.

To activate a U2F authenticator, the claimant is required to perform a test of user presence (TUP), which helps prevent unauthorized access to the authenticator’s functionality. In practice, a TUP consists of a simple button push.

Unlike mobile push authentication, the U2F authentication protocol runs entirely on the front channel but two round trips are required. The first round trip is ordinary password authentication. After the claimant has authenticated with a password, the verifier sends a challenge to the browser. A conforming browser communicates with the U2F authenticator via a custom JavaScript API. The authenticator requires a TUP before signing the challenge. Ultimately the browser returns the signed assertion to the verifier.

To verify the signature on the assertion, the verifier must maintain, or otherwise have access to, a store of trusted public keys. In contrast to mobile push, we assume the public-key infrastructure is not outsourced, but it certainly could be.

The U2F protocol depends on the origin (i.e., the domain) of the verifier. The authenticator creates a new key pair for each verifier, which has two important consequences. First, U2F is unlinkable, that is, two verifiers can not collude to correlate user behavior. Second, U2F is resistant to an active man-in-the-middle attack since a U2F authenticator will only issue a signed assertion if the actual verifier is in fact the expected verifier. The NIST Digital Identity Guidelines refer to this as resistance to verifier impersonation.

Comparing Single-Factor Authenticators

In this section, we compare five single-factor authenticators (Password, Extended Password, OATH OTP, Mobile Push, and FIDO U2F) using the evaluation framework in [Bonneau et al. 2012]. The Password scheme is analyzed in section III of [Bonneau et al. 2012] and used in Part 1 to compare Password and Password via SSO. The Extended Password scheme (also introduced in Part 1) assumes that users tend to reuse a single password across all sites (which enhances usability at the expense of security).

Assumptions

Beyond the two password schemes, we evaluate three (3) additional single-factor authentication schemes: OATH OTP, Mobile Push, and FIDO U2F. In each case, we assume a typical deployment model. The effects of exercising various deployment options are left to the discussion sections.

By OATH OTP, we mean either OATH HOTP or OATH TOTP. (The framework does not distinguish between the two.) We assume that the claimant uses a software authenticator running on a smartphone with at least PIN-based access control (to protect against loss or theft). Finally we assume that the verifier manages the shared keys locally (as opposed to outsourcing the shared-key infrastructure to a trusted third party).

The term Mobile Push refers to an out-of-band push notification received on a smartphone. Native apps that implement push authentication methods use public-key cryptography to demonstrate that the claimant possesses and controls the phone. We assume that the phone has at least PIN-based access control (to protect against loss or theft). We also assume that the necessary public-key infrastructure is outsourced to a trusted third party (which is how it’s usually done in practice).

The term FIDO U2F refers to Universal 2nd Factor, an authentication standard published by the FIDO Alliance. We assume that the claimant uses a hardware authenticator with a USB interface.

Benefits Table

In the table below, all of the benefits introduced by [Bonneau et al. 2012] plus the extended benefits defined in Part 1 are used to compare five (5) single-factor authentication schemes. The Password and Extended Password columns carried over from Part 1 are augmented with the extended benefits. The remaining 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
OATH
OTP
Mobile
Push
FIDO
U2F
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
OATH
OTP
Mobile
Push
FIDO
U2F

Comparison of Single-Factor Authenticators

⚫= 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 table shown above. This abbreviated table compares five (5) single-factor schemes for each of the original eight (8) usability benefits defined by [Bonneau et al. 2012].



Pass-
word
Ext.
Pass-
word
OATH
OTP
Mobile
Push
FIDO
U2F
U1Memorywise-Effortless
U2Scalable-for-Users
U3Nothing-to-Carry
U4Physically-Effortless


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




Pass-
word
Ext.
Pass-
word
OATH
OTP
Mobile
Push
FIDO
U2F

Comparison of Single-Factor Authenticators
Usability Benefits

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

U1. Memorywise-Effortless. The Password scheme is not Memorywise-Effortless while the Extended Password scheme is Quasi-Memorywise-Effortless from Part 1. All of the remaining single-factor schemes are Memorywise-Effortless since no memorized secret is involved.

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. Except for the Password scheme, all of the single-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 schemes are Nothing-to-Carry from Part 1. The OATH OTP and Mobile Push schemes are deemed Quasi-Nothing-to-Carry by the framework [Bonneau et al. 2012] since they are commonly implemented on a smartphone. The FIDO U2F scheme is not Nothing-to-Carry since a roaming hardware authenticator is assumed.

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. Both the Password and Extended Password schemes lack the Physically-Effortless benefit from Part 1. The OATH OTP scheme is not Physically-Effortless since the OTP must be generated and then manually entered into the web page. The Mobile Push scheme is Quasi-Physically-Effortless since the user must unlock the phone. The FIDO U2F scheme is Quasi-Physically-Effortless since the user must insert the authenticator into the USB slot (at least once per session). In the case of Mobile Push and FIDO U2F, the effort required to perform the test for user presence (i.e., to press a button) is negligible.

The USB interface is inherently usable

The FIDO U2F scheme is awarded the Quasi-Physically-Effortless since the USB interface is easy to use. Authenticators with other interfaces (such as near-field communication or Bluetooth Low Energy) may lose this benefit if more physical effort is required.

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. All of the single-factor schemes are Easy-to-Learn. In particular, the FIDO U2F scheme is fully Easy-to-Learn by virtue of its USB interface. Other interfaces (such as near-field communication or Bluetooth Low Energy) may be only Quasi-Easy-to-Learn.

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. Except for the OATH OTP scheme, all of the single-factor schemes are Efficient-to-Use. (While most implementations of the OATH OTP scheme lack this benefit, there are exceptions.)

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 scheme is Quasi-Infrequent-Errors while the Extended Password scheme is fully Infrequent-Errors from Part 1. With respect to the Infrequent-Errors benefit, the OATH OTP scheme is certainly no better than the Password scheme (and probably worse). We choose to award the Quasi-Infrequent-Errors benefit to the OATH OTP scheme. OTOH, the Mobile Push and FIDO U2F schemes are fully Infrequent-Errors.

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 schemes are Easy-Recovery-from-Loss from Part 1. None of the remaining schemes have this benefit, however.

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]

Deployability Benefits

The following table is an excerpt of the complete table shown above. This abbreviated table compares five (5) single-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
OATH
OTP
Mobile
Push
FIDO
U2F
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



Pass-
word
Ext.
Pass-
word
OATH
OTP
Mobile
Push
FIDO
U2F

Comparison of Single-Factor Authenticators
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 Mobile Push and FIDO U2F schemes are deemed Accessible since each requires a button push. The accessibility of the OATH OTP scheme depends on whether or not the user is both required and able to transcribe the OTP from the authenticator to the web page. We choose to withhold the Accessible benefit from the OATH OTP scheme until an implementation demonstrates accessibility.

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. None of the remaining single-factor authentication schemes has Negligible-Cost-per-User.

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. None of the remaining single-factor authentication schemes are Server-Compatible.

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. The OATH OTP and Mobile Push schemes are also Browser-Compatible. The FIDO U2F scheme is not Browser-Compatible since the required JavaScript API is not widely implemented across browsers.

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. All of the single-factor authentication schemes are Mature. To put this in perspective, the Mobile Push and FIDO U2F schemes reached maturation by 2015. The Password scheme and the OATH OTP scheme are much older technologies that predate the web itself. The Extended Password scheme is deemed to be Mature since the Password scheme is Mature.

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 OATH HOTP and TOTP are open specifications, the OATH OTP scheme is deemed Non-Proprietary. Likewise the FIDO U2F scheme is Non-Proprietary as well. OTOH, the Mobile Push scheme is not Non-Proprietary since the cryptographic algorithms used by a push authenticator are implementation specific and typically not well understood.

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. Except for the Password and Extended Password schemes (which serve as a baseline), none of the remaining single-factor authentication schemes have Negligible-Setup-Cost.

D8. Negligible-Support-Costs. Neither the Password scheme nor the Extended Password scheme have Negligible-Support-Costs from Part 1. Both the OATH OTP scheme and the Mobile Push scheme have Negligible-Support-Costs by virtue of their smartphone implementation. The FIDO U2F scheme is believed to have Quasi-Negligible-Support-Costs.

D9. Negligible-Fixed-Cost-per-User. Both the Password and Extended Password schemes have Negligible-Fixed-Cost-per-User from Part 1. None of the remaining single-factor authentication schemes have Negligible-Fixed-Cost-per-User.

D10. Negligible-Variable-Cost-per-Login. All of the single-factor authentication schemes have Negligible-Variable-Cost-per-Login.

Security and Privacy Benefits

The following table is an excerpt of the complete table shown above. This abbreviated table compares five (5) single-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
OATH
OTP
Mobile
Push
FIDO
U2F
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
OATH
OTP
Mobile
Push
FIDO
U2F

Comparison of Single-Factor Authenticators
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. All of the remaining single-factor schemes are fully Resilient-to-Physical-Observation since an attacker who observes the use of the phone or hardware device gains no useful information with which to impersonate the user. Even if the operation of the device were repeatedly observed, possession of the device (something you have) is still required for a successful login.

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. All of the remaining single-factor schemes are fully Resilient-to-Targeted-Impersonation since personal knowledge of the user can not be used to bypass the operation of the authenticator.

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 All of the remaining single-factor schemes are fully Resilient-to-Throttled-Guessing since the result of the cryptographic operation in each case is practically unguessable. Basically, possession of the device (something you have) is required for a successful login.

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. All of the remaining single-factor schemes are fully Resilient-to-Unthrottled-Guessing for the same reason they are fully Resilient-to-Throttled-Guessing (S3). Repeated guessing is not sufficient.

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 OATH OTP scheme is only Quasi-Resilient-to-Internal-Observation since malware might observe the OTP generated on the smartphone and race against the user to enter the OTP into the web page. The Mobile Push scheme is Resilient-to-Internal-Observation since there is nothing that can be stolen or replayed to impersonate the user. The FIDO U2F scheme is Resilient-to-Internal-Observation since the framework assumes that a hardware authenticator dedicated exclusively to the scheme can be made malware-free.

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. The OATH OTP scheme is Resilient-to-Leaks-from-Other-Verifiers since each verifier is assumed to share an unique secret with the claimant. The Mobile Push and FIDO U2F schemes are Resilient-to-Leaks-from-Other-Verifiers since they are based on public-key cryptography.

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. The OATH OTP scheme is Resilient-to-Phishing since OTPs can not be replayed at a later time. The FIDO U2F scheme is Resilient-to-Phishing since there is nothing in the authentication assertion payload that an attacker can leverage to subsequently impersonate the user. Likewise the Mobile Push scheme is Resilient-to-Phishing since there is nothing in either the authentication assertion or the response payload from the trusted third party that an attacker can leverage. Basically the FIDO U2F and Mobile Push schemes are Resilient-to-Phishing since they use public-key cryptography.

FIDO U2F is Resilient-to-Verifier-Impersonation

The FIDO U2F scheme is also resistant to an active man-in-the-middle attack (which the Resilient-to-Phishing benefit intentionally ignores). See S13.

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 manin-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. The OATH OTP and Mobile Push schemes are rated Quasi-Resilient-to-Theft since the smartphone is assumed to have adequate access controls. The FIDO U2F scheme is definitely not Resilient-to-Theft since a U2F authenticator does not support user verification.

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 have No-Trusted-Third-Party from Part 1. The OATH OTP scheme has No-Trusted-Third-Party since the verifier in each case is assumed to manage its own shared key infrastructure. The Mobile Push scheme does not have the No-Trusted-Third-Party benefit since a trusted third party is assumed to manage the public-key infrastructure in each case. The FIDO U2F scheme does not have the No-Trusted-Third-Party benefit since the hardware authenticator is manufactured by a third party.

Trusted Third Parties

The FIDO U2F scheme does not inherently lack the No-Trusted-Third-Party benefit since an open-source authenticator may work around this limitation. For example, the open-source Solo from SoloKeys may be awarded the full No-Trusted-Third-Party benefit.

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. All of the single-factor authentication schemes are Requiring-Explicit-Consent. The Password, Extended Password, and OATH OTP schemes are Requiring-Explicit-Consent since the user types a password (or one-time password) into the web page. The Mobile Push and FIDO U2F schemes are Requiring-Explicit-Consent since a test of user presence (TUP) is required.

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. The OATH OTP scheme is Unlinkable assuming the claimant uses a unique symmetric key for each verifier (which is a reasonable assumption). The Mobile Push scheme is Unlinkable since the verifier does not have direct access to the public key. The FIDO U2F scheme is inherently Unlinkable since the authenticator creates a new key pair for each verifier.

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. The OATH OTP scheme, however, is not No-Shared-Secrets-on-the-Server since a symmetric key is used. Both the Mobile Push and FIDO U2F schemes are awarded the full No-Shared-Secrets-on-the-Server benefit since only public keys are stored on the server.

S13. Resilient-to-Verifier-Impersonation. The FIDO U2F scheme is Resilient-to-Verifier-Impersonation by virtue of the U2F protocol. None of the remaining single-factor authentication schemes have this important security benefit.

Discussion

The security properties of the non-password schemes (OATH OTP, Mobile Push, and FIDO U2F) are significantly better than the password schemes. The following subsections highlight some of these properties.

Shared Secrets

Any scheme that depends on a shared secret does not have No-Shared-Secrets-on-the-Server. This includes the Password scheme and any scheme that uses symmetric-key cryptography since symmetric keys are shared secrets. For example, the OATH OTP scheme relies on symmetric-key cryptography and is therefore vulnerable to key compromise on the server as well as the client. Related to this, see section IV-H1 in [Bonneau et al. 2012] for historical notes regarding a well-known security incident involving the RSA SecurID scheme.

On the other hand, a cryptographic authenticator that uses public-key cryptography has No-Shared-Secrets-on-the-Server since the keys on the server are public keys, not shared secrets. For example, the Mobile Push and FIDO U2F authenticators are awarded this benefit.

Phishing

Except for the Password schemes, all of the single-factor schemes are Resilient-to-Phishing. As defined by the framework, this benefit does not tell the whole story, however. For example, the OATH OTP scheme is awarded the Resilient-to-Phishing benefit since an attacker that passively captures the OTP can not replay it at a later time. However, what if a more sophisticated attacker could capture the OTP and replay it in real time?

The Resilient-to-Phishing benefit (as defined by the authors of the framework) intentionally ignores the possibility of an active man-in-the-middle attack. We therefore introduce a new benefit that captures the notion of verifier impersonation, a scenario addressed in the NIST Digital Identity Guidelines. An authentication scheme is awarded the Resilient-to-Verifier-Impersonation benefit if it is resistant to an active man-in-the-middle attack.

Of the schemes evaluated, the FIDO U2F scheme is the only scheme that earns the Resilient-to-Verifier-Impersonation benefit. Note that the U2F authentication protocol provides this benefit, not the U2F authenticator per se. Use of the authenticator apart from the protocol may not be sufficient to earn this important benefit.

Authenticator Loss or Theft

A single-factor authenticator that is also something you have is inherently not Resilient-to-Theft. If the authenticator is lost or stolen, the authenticator secret is still usable by the unauthorized party who found or stole the authenticator. The FIDO U2F scheme lacks the Resilient-to-Theft benefit for this very reason.

OTOH, the OATH OTP and Mobile Push schemes are (generously) awarded the Quasi-Resilient-to-Theft benefit by virtue of the smartphone. Presumably the smartphone is locked, which prevents an unauthorized user from accessing the mobile application. However, the locking feature on the phone may be disabled, in which case there is no protection from loss or theft.

Single-factor schemes may be combined into multi-factor authentication schemes. If at least one of the single-factor schemes is Resilient-to-Theft, the combined multi-factor scheme is Resilient-to-Theft as well. See the next section for details.

Combining Single-Factor Authenticators

Given two single-factor authentication schemes, each with known benefits, combine the schemes into a two-factor authentication scheme as follows:

  1. If each authentication scheme has a particular usability benefit (or quasi- usability benefit), the combined two-factor authentication scheme also has that usability benefit (or quasi- usability benefit).

  2. If each authentication scheme has a particular deployability benefit (or quasi- deployability benefit), the combined two-factor authentication scheme also has that deployability benefit (or quasi- deployability benefit).

  3. If either authentication scheme has a particular security/privacy benefit (or quasi- security/privacy benefit), the combined two-factor authentication scheme also has that security/privacy benefit (or quasi- security/privacy benefit).

In other words, usability and deployability benefits are combined using logical AND while security/privacy benefits are combined using logical OR. Notable exceptions include benefits S9S12, which are computed using logical AND.

See section V-E in [Bonneau et al. 2012] for further discussion along these lines.

Benefits Table

Using the results for Extended Password, OATH OTP, and Mobile Push obtained previously, let’s compute the benefits of the two-factor authentication schemes Extended Password + OATH OTP and Extended Password + Mobile Push:



Ext.
Pass-
word
OATH
OTP
Mobile
Push
Ext.
Pass-
word
+
OATH
OTP
Ext.
Pass-
word
+
Mobile
Push
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






Ext.
Pass-
word
OATH
OTP
Mobile
Push
Ext.
Pass-
word
+
OATH
OTP
Ext.
Pass-
word
+
Mobile
Push

Combining Single-Factor Authenticators

⚫= 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.

Multi-Factor Authenticators

Multi-factor authentication does not necessarily require a multi-factor authenticator (as the previous example illustrates). In Part 3, the Extended Password + FIDO U2F two-factor scheme is compared to the Passwordless scheme, which relies on a multi-factor authenticator.

Discussion

In general, a two-factor authentication scheme inherits its characteristics from the individual single-factor schemes. In terms of usability and deployability, a two-factor scheme is as strong as its weakest factor, but in terms of security, a two-factor scheme is as strong as its strongest factor.

Both the Extended Password + OATH OTP and the Extended Password + Mobile Push two-factor schemes have excellent security properties. This is due to the strong security features of the OATH OTP and Mobile Push (resp.) authenticators, each of which masks the security weaknesses of the Extended Password authenticator.

The Extended Password + Mobile Push two-factor scheme has good usability characteristics while the Extended Password + OATH OTP two-factor scheme has some weaknesses, which are due to flaws in the OATH OTP scheme itself. In any case, if you replace the Extended Password scheme by the Password scheme in the table above, the usability of both two-factor schemes is significantly reduced. This phenomenon is generally true of two-factor schemes that rely on the Password scheme: the overall usability of the two-factor scheme is degraded by the poor usability of the Password scheme.

Recall that the framework awards all deployability benefits to the Password scheme, which is used as a baseline. (However, in the extended framework, the Password scheme does not have Negligible-Support-Costs.) Consequently, the Extended Password scheme is awarded all deployability benefits as well (since the Extended Password scheme differs from the Password scheme in terms of usability only).

The benefits table suggests that both the Extended Password + OATH OTP and the Extended Password + Mobile Push two-factor schemes have significant deployment issues. Since the Extended Password scheme is deployable by definition, these issues are due to the deployability characteristics of the OATH OTP and Mobile Push (resp.) authenticators themselves. We will revisit this issue in Part 4.

Evaluating Google Security Keys

In this section, we examine a case study regarding Google Security Keys. As the term is used here, a “Security Key” is a hardware-based U2F authenticator, that is, the case study reports on an extensive deployment of the Password + FIDO U2F two-factor authentication scheme. As it turns out, a detailed report published by Google uses the evaluation framework of [Bonneau et al. 2012] to compare Security Keys to other authentication schemes.

Our evaluation of the Password + FIDO U2F scheme differs from Google’s evaluation of Security Keys in a number of important aspects. These differences are discussed in the sections that follow.

Benefits Table

The Password scheme is analyzed in section III of [Bonneau et al. 2012] and applied in Part 1. Using the FIDO U2F scheme evaluated above, along with the algorithm for combining schemes illustrated in the previous section, it is straightforward to determine the benefits of the Password + FIDO U2F scheme. The Google Security Keys column is a faithful reproduction of the benefits claimed in Google’s published report.



Pass-
word
FIDO
U2F
Pass-
word
+
FIDO
U2F
Google
Security
Keys
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


NA
D8Negligible-Support-Costs


NA
D9Negligible-Fixed-Cost-per-User


NA
D10Negligible-Variable-Cost-per-Login
NA
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-ServerNA
S13Resilient-to-Verifier-Impersonation
NA


Pass-
word
FIDO
U2F
Pass-
word
+
FIDO
U2F
Google
Security
Key

Evaluating Google Security Keys

⚫= 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.

Usability Benefits

The Google Security Keys scheme is rated better than the Password + FIDO U2F scheme with respect to three usability benefits: Memorywise-Effortless, Scalable-for-Users, and Infrequent-Errors. We will show that these ratings are overly optimistic. Rather than try to refute Google’s claims, we now rate the Google Security Keys scheme with respect to usability and justify those ratings based on previous arguments.

The Google Security Keys scheme is Quasi-Infrequent-Errors (not fully Infrequent-Errors as claimed by Google) since the Password scheme is deemed Quasi-Infrequent-Errors by the framework. As a standalone single factor, the FIDO U2F scheme does not increase (or decrease) the frequency of errors.

Contrary to Google’s claims, the Google Security Keys scheme lacks both the Memorywise-Effortless and Scalable-for-Users benefits since the Password scheme lacks these benefits. The single-factor FIDO U2F scheme does not offset the penalty incurred by using the Password scheme as a first factor.

If we assume that users reuse a single password across all sites, then there is just one password to juggle and so usability is improved. Using arguments similar to those applied by [Bonneau et al. 2012] to the federated schemes (OpenID, etc.), we conclude that the Google Security Keys scheme is Quasi-Memorywise-Effortless, fully Scalable-for-Users, and fully Infrequent-Errors under this new assumption. This is as good as it gets for a two-factor scheme based on the Password scheme.

These observations suggest that, in terms of usability, the Google Security Keys scheme (like the Password via SSO scheme in Part 1) tends to legitimize existing user behavior. For details, see the Extended Password scheme introduced in Part 1. See also the Extended Password + FIDO U2F scheme computed in Part 3.

We strongly agree with Google that the Google Security Keys scheme lacks the Nothing-to-Carry and Easy-Recovery-from-Loss benefits. In fact, any scheme that incorporates the FIDO U2F scheme as a second factor, lacks these important benefits. These deficiencies are discussed more thoroughly in Part 3.

Deployability Benefits

Google awards the Quasi-Negligible-Cost-per-User benefit to the Google Security Keys scheme and provides evidence that the scheme has reduced supports costs. While the latter is convincing, we claim that hardware costs are still significant and so we would be inclined to withhold the Negligible-Cost-per-User benefit until the fixed cost per user becomes sufficiently small.

Browser compatibility

Google awards the Quasi-Browser-Compatible benefit to the Google Security Keys scheme. Since Google published this report, however, browser compatibility has completely changed. In particular, the legacy U2F protocol has been superseded by the Web Authentication (WebAuthn) protocol. Browser support for the latter is very good and getting better. See Part 3 for details.

Security and Privacy Benefits

Both the Password + FIDO U2F and the Google Security Keys schemes are Resilient-to-Phishing but Google alters the original definition of the benefit to include active man-in-the-middle attacks. Instead we introduce an extended benefit (called Resilient-to-Verifier-Impersonation) in Part 1. In any case, the conclusion is the same: the U2F protocol protects against an active man-in-the-middle attack.

The Google Security Keys scheme has No-Trusted-Third-Party since Google manages the necessary public-key infrastructure (PKI). OTOH, the Password + FIDO U2F scheme does not have the No-Trusted-Third-Party benefit since PKI management is assumed to be outsourced. Until there is an existence proof (apart from Google and other large companies) that outsourcing can be easily avoided, we choose to withhold the No-Trusted-Third-Party benefit.

For further discussion along these lines, see the Extended Password + FIDO U2F and the Passwordless schemes introduced in Part 3.


  • No labels