Internet2 is investigating a security incident involving a compromise to a confluence server that affected https://spaces.at.internet2.edu on April 10, 2019, which was successfully mitigated on April 12, 2019. If you did not receive an email from us, it’s unlikely that any of the content you submitted to the Internet2 Spaces Wiki needs to be re-entered. We apologize for any inconvenience this may have caused. Should you have any questions or require further assistance, please email collaboration-support@internet2.edu.
Child pages
  • The Quest to Replace Passwords
Skip to end of metadata
Go to start of metadata

The above title is borrowed from a fascinating research paper by J. Bonneau et al. [1] Therein “two decades of proposals to replace text passwords for general-purpose user authentication on the web” are compared and evaluated using an explicit framework designed by the authors. Their work follows on the previous work of two of the same authors calling for a research agenda based on the assumption that

the "password replacement problem" is both underspecified and over-constrained. [2]

Of course one should always be careful what one asks for. The goal is not necessarily to replace passwords (indeed, the authors argue strongly that this is not likely to happen any time soon), but rather the quest is for an authentication technology that retains the strengths of passwords but at the same time eliminates their weaknesses. Thus the title of the current paper might more accurately be:

The quest to find a web authentication technology that is as easy to deploy and at least as usable as passwords, but significantly more secure.

Whether that’s some password variant or some completely new technology remains to be seen.

Contents:

Part I: Password vs. Federated Password

s/Password/Federated Password/g

Methodology

A total of 38 authentication schemes are evaluated in [1] and we include the original authors' comprehensive benefits matrix here for cross-reference. Of particular interest is their detailed treatment of ordinary passwords (see section III of [1]), reproduced here (in the Password column in the table below) solely for convenience.

In this Part I, we critically analyze a small sampling of the authentication schemes studied in [1] and then introduce a new Federated Password scheme, which is more-or-less equivalent to the evaluation of OpenID in section IV-C1 of [1]. The choice of schemes to study here is strategic, as noted in the following sections.

The 25 benefits listed in the tables below are the same as those identified in section II of [1]. The Federated Password scheme is compared and contrasted to the Password scheme according to these benefits.

Executive Summary

Federated Password has some significant security and usability benefits over Password alone. On the other hand, Federated Password is not nearly as deployable as ordinary Password, a fact not made readily apparent by the framework. Moreover, while the framework exposes other disadvantages of Federated Password, the significance of those disadvantages are only made clear upon deeper reflection and further analysis.

Introduction

The framework developed in [1] is valuable for a number of reasons. First, it introduces terminology that facilitates discussion and comparison of alternative authentication technologies. Second, it illustrates how the framework might be applied to a large number of authentication schemes, and in so doing, lays the groundwork for further utilization of the framework.

We begin by analyzing five key authentication schemes studied in [1]. These are Password, OpenID, OTP over email, OTP over SMS, and Google 2-Step Verification. We focus on this small subset of the total 38 schemes evaluated in [1] since each has significant overlap with one or more of the two-factor authentication schemes studied in Part II.

The table below faithfully reproduces from [1] the five schemes of interest (see the attached benefits matrix for the original presentation of these results in [1]). These schemes are critically evaluated in the following subsection.

 

 

 

U1

Memorywise-Effortless

U2

Scalable-for-Users

U3

Nothing-to-Carry

U4

Physically-Effortless

U5

Easy-to-Learn

U6

Efficient-to-Use

U7

Infrequent-Errors

U8

Easy-Recovery-from-Loss

D1

Accessible

D2

Negligible-Cost-per-User

D3

Server-Compatible

D4

Browser-Compatible

D5

Mature

D6

Non-Proprietary

S1

Resilient-to-Physical-Observation

S2

Resilient-to-Targeted-Impersonation

S3

Resilient-to-Throttled-Guessing

S4

Resilient-to-Unthrottled-Guessing

S5

Resilient-to-Internal-Observation

S6

Resilient-to-Leaks-from-Other-Verifiers

S7

Resilient-to-Phishing

S8

Resilient-to-Theft

S9

No-Trusted-Third-Party

S10

Requiring-Explicit-Consent

S11

Unlinkable

A Sample of Authentication Schemes Taken From [1]
 = 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.

Critical Evaluation

The evaluation framework of interest is defined in section II in [1]. The framework is illustrated in section III in [1] where the authors apply it to ordinary passwords. Thus the Password scheme is the baseline authentication scheme against which all alternatives are compared.

OpenID

In the original paper, OpenID is ultimately awarded the Requiring-Explicit-Consent benefit but oddly this is not discussed in section IV-C1 in [1] so we can only guess the authors’ intent. Perhaps OpenID is thought to require explicit consent for the same reason it is only Quasi-Easy-to-Learn, that is,

selecting an opaque "identity URL" can be a significant usability challenge

for the user. Lacking any evidence to the contrary, we will assume this to be the case.

In Table I in [1] note that OpenID is lacking the Unlinkable benefit, no doubt because the “identity URL” mentioned above can be used to correlate user activity across relying parties. There is, however, nothing in the OpenID specification that makes it inherently non-Unlinkable. Indeed, the ICAM OpenID 2.0 Profile mandates the identity provider to issue different identifiers (so-called Private Personal Identifiers) to different relying parties. We therefore prefer to associate the Unlinkable benefit with the OpenID scheme (and thus award the Unlinkable benefit to the Federated Password scheme in the sequel).

As a side note, the general treatment of federated password schemes in section IV-C in [1] is enlightening. A glance at Table I in [1] suggests that federated passwords are more usable and more secure than ordinary passwords, whereas federated passwords are lacking in terms of deployability and privacy. The reader is invited to study [1] (especially the related remarks in section V-A) more closely to determine if our claims are in fact justified.

OTP over email

Retrieving a one-time password (OTP) via email is a kind of federated authentication where the email provider is acting as the identity provider. Although OTP over email has inherent usability problems, it is ideal for exceptional situations such as password reset and other seldom performed operations.

"Simple Authentication for the Web" (SAW) [3] is a specific protocol for OTP over email that binds the entire authentication sequence to a single browser using cookies (not JavaScript, as suggested in [1]). Clearly SAW is only as strong as the user's email provider. That said, from a security perspective, SAW is stronger than OpenID in the sense that SAW does not involve redirects (and is therefore not susceptible to phishing).

OTP over SMS

OTP over SMS is evaluated in [1] as an independent authentication scheme (i.e., not in conjunction with two-factor authentication). As such it represents an entire class of important cross-channel methods (section IV-I4). Its importance here is due to the fact that one of the authentication schemes studied in Part II requires identical user operations (namely, transcribing a numeric OTP into a web application) and therefore we expect the usability of this new scheme to inherit from OTP over SMS.

Google 2-Step

Of the 38 authentication schemes studied in [1], Google 2-Step Verification is most like the two-factor authentication schemes studied in Part II. In particular, all of these schemes rely on a mobile phone for the second factor. However, a variant of Google 2-Step (that uses cookies to limit the phone-based challenge to once every 30 days) is analyzed in section IV-I5 in [1]. Fortunately the authors include numerous remarks about the full Google 2-Step scheme, which is extremely helpful for our purposes.

In section IV-I5 in [1] the authors claim that

Google 2-Step is Resilient-to-Theft because it requires a password in addition to possession of the phone.

We disagree with this conclusion. At best, Google 2-Step Verification is Quasi-Resilient-to-Theft assuming the phone is passcode-protected (for the same reason OTP over SMS is Quasi-Resilient-to-Theft). This is because the attacker has access to the user’s e-mail on the phone and can therefore reset the password using the phone itself.

In addition the passcode on the phone needs to be Resilient-to-Throttled-Guessing, otherwise the attacker can guess the passcode and use the lost/stolen phone to complete the login. If, on the other hand, the phone is not passcode-protected (which is the more conservative assumption), then all is lost. It is therefore debatable whether Google 2-Step Verification is even Quasi-Resilient-to-Theft. We will revisit this important question in the discussion section in Part II.

Federated Password

By “Federated Password” we mean password authentication in conjunction with either OpenID 2.0 or SAML V2.0 Web Browser SSO since we will show that both are equivalent under the current framework (which says something about the framework itself). It may be true that the emerging OpenID Connect protocol is equivalent as well (as suggested in [1]) but this author is not equipped to make that claim.

The evaluation of the Federated Password scheme follows directly from the evaluation of OpenID in section IV-C1 in [1] since the same arguments apply to SAML Web Browser SSO. Moreover, the critical remarks about OpenID in the previous section also apply to SAML Web Browser SSO:

  • The Requiring-Explicit-Consent benefit is awarded to the Federated Password scheme since SAML identity provider discovery (which is normally the prelude to SP-initiated SAML Web Browser SSO) requires an explicit action on the part of the user.
  • The Federated Password scheme is Unlinkable since a SAML Persistent NameID (a form of Private Personal Identifier) may be used.

The benefits associated with the Federated Password scheme are compared to the ordinary Password scheme in the table below.

 

 

U1

Memorywise-Effortless

U2

Scalable-for-Users

U3

Nothing-to-Carry

U4

Physically-Effortless

U5

Easy-to-Learn

U6

Efficient-to-Use

U7

Infrequent-Errors

U8

Easy-Recovery-from-Loss

D1

Accessible

D2

Negligible-Cost-per-User

D3

Server-Compatible

D4

Browser-Compatible

D5

Mature

D6

Non-Proprietary

S1

Resilient-to-Physical-Observation

S2

Resilient-to-Targeted-Impersonation

S3

Resilient-to-Throttled-Guessing

S4

Resilient-to-Unthrottled-Guessing

S5

Resilient-to-Internal-Observation

S6

Resilient-to-Leaks-from-Other-Verifiers

S7

Resilient-to-Phishing

S8

Resilient-to-Theft

S9

No-Trusted-Third-Party

S10

Requiring-Explicit-Consent

S11

Unlinkable

Comparison of Password and Federated Password
 = 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.

Discussion

The framework clearly shows the advantages of Federated Password over Password alone. Here we concentrate the discussion on those benefits where the opposite is true.

The Role of User Interfaces

Note that Federated Password is only Quasi-Easy-to-Learn. This is because Federated Password, by definition, implies cross-domain single sign-on, which seems to require user interaction at the service provider. After years of research and experimentation, the optimal discovery interface is still not in widespread use (and indeed, may not yet have been found), but it is doubtful that discovery can be eliminated altogether since such a scheme would lack the Requiring-Explicit-Consent benefit.

Speaking of which, the Requiring-Explicit-Consent benefit needs some clarification since it’s not clear what the user is consenting to according to this framework. There’s a wide range of technical behaviors that might require user consent, starting with cookie-based authentication at the one end, all the way to the explicit release of Personally Identifiable Information at the other end of the spectrum. One might argue that the user should control all of this, which seems to imply multiple user interfaces.

It doesn’t seem likely we will be able to avoid at least one user interface (in addition to the login interface) in a federated single sign-on scenario. Today most identity providers assert transient identifiers by default, which don’t require user interaction at the identity provider, but frankly, if that’s all we can expect from federation, it’s probably not worth the effort. Without persistent identifiers and/or other user attributes, there’s little if any opportunity for personalization or access control at the SP. However, attribute release implies user consent of one form or the other, and user consent implies a user interface.

Conclusion: Federation requires one or more user interfaces, but good user interface design is hard. There is still work to be done in terms of optimizing UIs used in conjunction with federation.

Consolidating the Authentication Secret

Note that Federated Password is Quasi-Resilient-to-Unthrottled-Guessing and Resilient-to-Leaks-from-Other-Verifiers, a pair of related benefits that represent a significant improvement over Password alone. However, the consolidation of passwords at the identity provider has a corresponding downside (not captured by the current framework), and that is, federated password stores become extremely attractive targets requiring significantly more care and protection than any simple password file at a non-federated service provider (unless you believe that most users use the same password across service providers, in which case a simple password may be just as valuable as a federated password).

In any case, effective federation requires a quantifiable level of assurance (LoA) at the identity provider. Without some form of LoA, a non-federated service provider is hesitant to federate in the first place, and rightly so. Every successful federation is based on a trust framework that assures service providers that identity provider(s) can be trusted to do the Right Thing. This notion is reinforced by the No-Trusted-Third-Party benefit, which of course is lacking in the case of Federated Password.

Conclusion: To effectively replace Password with Federated Password, a corresponding level of assurance at the identity provider is needed. Indeed, there can be no effective federation without LoA.

Deployment Issues

There is no question that Federated Password lacks the Server-Compatible benefit as shown in [1] but a deeper analysis will show that the choice to federate at the service provider is not a simple one. This is especially true in the case of an existing webapp that already incorporates a well-entrenched login interface, since in that case the entire authentication mechanism needs to excised from the application. For some applications, this can be a daunting task.

References

[1] Joseph Bonneau, Cormac Herley, Paul C. van Oorschot, Frank Stajano. "The quest to replace passwords: a framework for comparative evaluation of Web authentication schemes," Technical Report Number 817, University of Cambridge Computer Laboratory, March 2012. http://t.co/VUdl7VNb

[2] Cormac Herley, Paul C. van Oorschot. "A Research Agenda Acknowledging the Persistence of Passwords," August 2011. http://research.microsoft.com/apps/pubs/?id=154077

[3] Timothy W. van der Horst, Kent E. Seamons. "Simple Authentication for the Web," Intl. Conf. on Security and Privacy in Communications Networks, 2007, pp. 473–482.

  • No labels