The quest to replace passwords

May 22nd, 2012 at 16:37 UTC by Frank Stajano

As any computer user already knows, passwords are a usability disaster: you are basically told to “pick something you can’t remember, then don’t write it down“, which is worse than impossible if you must also use a different password for every account. Moreover, security-wise, passwords can be shoulder-surfed, keylogged, eavesdropped, brute-forced and phished. Notable industry insiders have long predicted their demise. Over the past couple of decades, dozens of alternative schemes have been proposed. Yet here we are in 2012, still using more and more password-protected accounts every year. Why? Can’t we do any better? Don’t the suggested replacements offer any improvements?

The paper I am about to present at the IEEE Symposium on Security and Privacy in San Francisco (Oakland 2012), grown out of the “related work” section of my earlier Pico paper and written with coauthors Joe Bonneau, Cormac Herley and Paul van Oorschot, offers a structured and well-researched answer that, according to peer review, “should have considerable influence on the research community”. It offers, as its subtitle says, a framework for comparative evaluation of password replacement schemes.

We build a large 2D matrix. Across the columns we define a broad spectrum of 25 benefits that a password replacement scheme might potentially offer, starting with USABILITY benefits, such as being easy to learn, or not requiring a memory effort from the user, and SECURITY benefits, such as resilience to shoulder-surfing or to phishing. These two broad categories, and the tension between them, are relatively well-understood: it’s easy to provide more usability by offering less security and vice versa. But we also introduce a third category, DEPLOYABILITY, that measures how easy it would be to deploy the scheme on a global scale, taking into account such benefits as cost per user, compatibility with deployed web infrastructure and accessibility to people with disabilities.

Next, in the rows, we identify 35 representative schemes covering 11 broad categories, from password managers through federated authentication to hardware tokens and biometric schemes. We then carefully rate each scheme individually, with various cross-checks to preserve accuracy and consistency, assessing for each benefit whether the given scheme offers, almost offers or does not offer the benefit. The resulting colourful matrix allows readers to compare features at a glance and to recognize general patterns that would otherwise be easily missed.

Contrary to the optimistic claims of scheme authors, who often completely ignore some evaluation criteria when they assert that their scheme is a definite improvement, none of the examined schemes does better than passwords on every benefit when rated on all 25 benefits of this objective benchmark.

From the concise overview offered by the summary matrix we distil key high level insights, such as why we are still using passwords in 2012 and are probably likely to continue to do so for quite a while.

How can we make progress? It has been observed that many people repeat the mistakes of history because they didn’t understand the history book. In the field of password replacements, it looks like a good history book still needed to be written! As pointed out during peer review, our work will be a foundational starting point for further research in the area and a useful sanity check for future password replacement proposals.

An extended version of the paper is available as a tech report.

Entry filed under: Academic papers, Authentication, Usability

8 comments Add your own

  • 1. Ben  |  May 22nd, 2012 at 18:23 UTC

    PasswordSafe not on there? What about RoboForm?

    Looks like Password Safes including Firefox are winning.

    I.e. just use a username and password, but have a password manager to manage them all.

  • 2. Von  |  May 23rd, 2012 at 18:53 UTC

    Nice work. Have you considered how different password policies fit into this? For example, at some level of complexity “nothing to carry” seem to no longer be true as the password is no longer memorable.

  • 3. Sorpigal  |  May 24th, 2012 at 13:34 UTC

    It seems pretty clear from this that federated services are the best place to start from if you’re designing the next password replacement system. They generally score well in most categories and are worse than passwords in some, but not many, categories.

    A new scheme that starts with a federated system and aims to address each point which makes existing federated systems worse than passwords would seem to be a short path to something comprehensively better.

    I’d also like to point out that not all “online” password managers require a trusted third party, for certain discrete values of “trusted.” It’s possible to offer a level of encryption (client side) which renders trust of the third party host effectively unnecessary. All encryption can be brute forced “eventually”, but there ways around that too (like periodic, automatic generation of a new encryption key and re-encryption of the entire data set).

  • 4. Bob  |  May 24th, 2012 at 14:12 UTC

    Interesting to see an analysis of things like LastPass combined with a Yubico key, Google Autheticato, a fingerprint reader built into my laptop. I am a big fan of LastPass because they’ve built the flexibility and features to extend it to be more secure while quasi-convenient.

  • 5. Alapan  |  May 24th, 2012 at 16:31 UTC

    An excellent analysis of the various technologies – very useful too. The great value in this paper, is the excellent analysis of all the factors that should be considered for all alternatives, such as cost, and coverage of security threats.

    I do have a criticism though, that the actual password policies are themselves not examined – which often lead to weak passwords IMO.

    For example, I created an online account related to financial services this past week. The password policy had restrictions on maximum length, type of characters used (no spaces), requirement for numbers and special characters. All these contribute against “easy to learn”, “efficient to use” and “infrequent errors”. However a good password policy that focuses on passphrases would easily overcome these usability challenges.

  • 6. Jack  |  May 25th, 2012 at 21:18 UTC

    Really great work. Tough to beat username/password in many respects unfortunately. But I would caution that “it’s all about the context”. Some of these solutions would actually outperform username/password depending on the context. For instance, enterprise remote access service and OTP over SMS is a perfect match in my estimation. But OTP/SMS might be problematic in an office situation.

  • 7. Tom  |  June 4th, 2012 at 19:53 UTC

    Great paper! Applied the framework to a handful of two-factor authentication schemes. Some key benefits are missing but the framework facilitates discussion and comparison of alternatives.

    Definitely agree with Sorpigal with respect to federated schemes. Not sure why the authors think “Federated schemes are particularly hard to grade.” See above page for examples.

  • 8. Sitaram Chamarty  |  June 8th, 2012 at 06:37 UTC

    How would you rate something like hashapass? It’s sort of like a password manager but no 3rd party.

    In fact it boils down to this code


    echo -n "$domain$salt" |
    openssl sha1 -binary -hmac "$masterpassword" |
    openssl base64 |
    cut -c1-${pwlen:-14}

    The salt needs to be remembered for each domain (like if you were forced to change the password for some reason you might use a salt of “2″, then “3″ etc). About the only thing an “app” is needed for here is to remind you of the salt for a site, and it need not be secret.

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Subscribe to the comments via RSS Feed


Calendar

May 2012
M T W T F S S
« Apr   Jun »
 123456
78910111213
14151617181920
21222324252627
28293031