Ben Laurie blathering

Do Passwords Scale?

Today I spent an hour with a bunch of academics. Each of the panellists had to talk for a few minutes to set the scene. I decided to talk about the worst usability disaster ever, namely passwords.

The problem with passwords is that we pin all our security on them. Although I can imagine a future world where we pin our security on other things, like strong credentials, I still wonder how that world really looks?

In particular, when I buy the latest Mac, how do I get it all signed up with all these credentials? It seems to me that the only usable answer to that question is that I fetch them from the cloud. How do I do that? Ultimately, with a password of some kind. Yes, you can back it up with a dongle or something, but when I lose that, how do I get a new one? I call you and give you … a password (of course I include my mother’s maiden name, my postcode, my date of birth, the name of my first and most beloved hamster and all that other nonsense as passwords). And if I only ever do this every couple of years, how easy is it to persuade me to do it wrong? Pretty damn easy, if you ask me. And you did.

So, where does this leave us? Users must have passwords, so why fight it? Why not admit that its where we have to be and make it a familiar (but secure) process, so that users can actually safely use passwords, phishing-free?

The answer to this is deeply sad. It is because we have done a fantastic job on usability of passwords. They’re so usable that anyone will type their password anywhere they see the word “password” with a box next to it. Phishing is utterly trivial because we have trained the world to expect to be phished every time they see a new website.

Of course, we can fix this cryptographically – that’s easy. But let’s say we did that. How do we stop the user from ever typing their password into a phishable box from this day forward? So long as they only ever type the password into the crypto gadget that does the unphishable protocol, they are safe, no matter who asks them to log in. But as soon as they type it into a text box on a web page, they’re screwed.

So, this is why passwords are the worst usability disaster ever.

Anyway, now to the title. Suppose we get to this utopia, an academic suggested, we’d still be screwed because passwords don’t scale. Because, of course, we need a different password for each site we log in to.

Well, no. If your password is unphishable, then it is obviously the case that it can be the same everywhere. Or it wouldn’t be unphishable. The only reason you need a password for each site is because we’re too lame to fix the real problem. Passwords scale just fine. If it wasn’t for those pesky users (that we trained to do the wrong thing), that is.


  1. I am not sure how the crypto gadget protocol you propose is supposed to work but as long as the password I type in there is send over (encrypted of course) to the backend and recoverable there as plaintext password, you have to trust it is stored/used securely there. There are umpteen cases where user passwords are saved in backend database in plaintext. Backend compromise is one of the reasons why I keep different password for different services.

    Comment by Srijith — 26 Nov 2008 @ 14:23

  2. “If your password is unphishable, then it is obviously the case that it can be the same everywhere. Or it wouldn’t be unphishable.”

    This does assume that everywhere you use it actually secures your password, and doesn’t just store it as plain text. That’s my reason for using multiple password: not because of possible phishing attacks, but because so many places store raw passwords with weak or no encryption.

    Comment by Thomas — 26 Nov 2008 @ 19:06

  3. Why not a call and response system?

    I give you six images, you present them in interesting and quick ways that are awfully difficult to crack but easy for me to work my way through.

    Can’t phish that, of course, since the phisher doesn’t know the images, right?

    Comment by Seth Godin — 26 Nov 2008 @ 19:08

  4. You don’t need to transmit the password either encrypted or in cleartext over the network to be secure.

    They just need to agree a protocol and push the username/passwords back into the OS. Perhaps some variant of Kerberos?

    Comment by Jason — 26 Nov 2008 @ 21:55

  5. In the world of security there are no absolutes, and usually not even any superlatives. That means there is no such thing as a system that is unhackable, or a password that is uncrackable. Even with perfect or near-perfect hardware, somebody will always find a way to game the system via social engineering. Mythical crypto-gadgets simply won’t save the day. All somebody has to do is replace your crypto-gadget with an identical-looking crypto-gadget of their own making and now it becomes the new “password” input field that is so phishable, and you’re back to square one. Using different passwords for each site will always be a good idea, to make it less likely that once your password *is* eventually hacked it won’t be universally usable.

    Comment by kmoser — 26 Nov 2008 @ 22:04

  6. One additional problem in the password realm is the number of sites that require you to have a password to read content that they are essentially giving away for free. There is no reason for The New York Times or The Washington Post to need me to log in, except that is the system they are using to gather information for their advertisers. And there are lots and lots of occasions where that comes up. I mostly don’t bother when, for example, “registration” is required in order comment on a blog. Most often in such cases it’s not MY security that is at issue, but rather the site’s management of information about its users.

    Also, why are credit card companies bothering with “security codes” on their card when pretty much any site on the web that wants your credit card info also wants your security code to process the transaction. Doesn’t that defeat the purpose of having such things?

    Comment by Kathryn Cramer — 26 Nov 2008 @ 22:11

  7. The cryptogadget could “just” be a cryptographical secure hasher built into a web standard so it’s part of the browser – it doesn’t matter what the server gets as long as it can be resolved to be the right input in the first place. Unix systems have had to deal with a user readable password file for decades without sacrificing a huge amount of security so they use hashes.

    If you don’t let people transmit plaintext passwords in the first place then the most that the phishers have to work with is a heavily salted hash, surely?

    Comment by Stephen — 26 Nov 2008 @ 22:39

  8. Most websites truly do not need passwords, that is the big problem. But it seems to them the easiest way to keep bots from defacing the interactivity of their site. Someone just needs a way to fend off the bots and trolls and spammers.

    If you have to remember tens of passwords for more trivial purposes, soon no passwords have any value.

    Comment by bud — 26 Nov 2008 @ 23:43

  9. I sometimes wonder if the correct solution to the password problem is to start password training at age 5, just after numbers and the alphabet.

    Comment by Alex Burr — 26 Nov 2008 @ 23:53

  10. @#4: “They just need to agree a protocol and push the username/passwords back into the OS.”

    As Ben said, the crypto is the easy part. The problem is that, as a user, you can’t tell what kind of algorithm a password text-field feeds into. As long as websites are allowed to put up text fields and arbitrary graphics, phishers can make official-looking password screens that people will reflexively type passwords into. At that point it’s game-over, since the page can just send your raw password directly back to the phisher.

    Comment by Jens Alfke — 27 Nov 2008 @ 0:34

  11. We need to train users to expect web sites to state *their* password before the user enters theirs and not to trust “password” boxes on websites that haven’t provided any credentials to the user. It’s ridiculous to expect users to mistrust phishers without the genuine site offering them any evidence of genuineness.

    I have received e-mail from well-known e-commerce sites inviting me to click on links to pages which are not even on the same domain as I originally signed up on, whereupon I am expected to enter my credentials in order to participate in the promotion. How is anyone supposed to distinguish that from a phishing e-mail?

    It’s up to the industry to lift the standards, which sadly are currently quite low.

    Comment by Adelle — 27 Nov 2008 @ 6:38

  12. In regards to the question of how to stop people entering their password into just anywhere that asked for it – I always found the two step process used by some sites (BoA uses one, I think they call it SiteKey) to be quite strong. The initial log-in is just a username of some sort, which then takes you to a page with some sort of validation you chose (an image and/or a key phrase) and a space to enter your password. I log in as ‘brendan’, and then am sent to a page, and if that page doesn’t say “I like pork chops” then I know not to enter my password. It scales to any site, really – although of course the system is still spoofable if people know my login name so they can check the site itself to find my key phrase before phishing me. But I think in 99.9% of situations, this approach stops you from entering your password into the wrong site.

    As for passwords not scaling because we need different ones for each site, I think they do scale if handled properly, even disregarding some sort of universal password grabbed from a cloud. The easy answer is just having some sort of dependent, relatively simple way to transform some part of the site into a password. It’s not entirely secure, but it’s better than the passwords virtually everyone uses, and is fairly easy. It’s what I do, and I’m certainly no genius when it comes to quick transforms in my head. And with a few added steps you can make them much stronger as passwords, while still scaling up.

    As an example, let’s take this site ( and pretend I needed a password for it. I could take the first subdomain of URL (links) and transform it according to some rule I use for every single one of my passwords – let’s say I offset the letters by three. So I wind up with ‘olqnv’. Then I use some other set rule – let’s say I add the number of characters to the beginning once and the end twice, and capitalize the second letter. So I wind up with ‘5oLqnv55’. Certainly not the strongest password on earth, but fairly strong. And although it requires me remembering only a few simple rules (offset letters by three, add number of letters once to beginning, twice to end, capitalize second letter), it scales to whatever site I might ever join.

    These two things combined don’t make for a perfect system, but they make for a darn strong system that requires only slightly more work than we have now.

    On a different note – I hate character limits for passwords. I feel like even with the systems exactly like we have now, I could have people make much, much stronger passwords if I could just tell them to have their passwords be a full phrase they’ll never forget. If people could just use ‘tieayellowribbonroundtheoldoaktree’ as their password, they would, would forget it less often than ‘Mommy84’, and it would be less susceptible to hacking. Sigh.

    Comment by brendan mcguigan — 27 Nov 2008 @ 10:33

  13. Indeed, the UNIX password file design has been remarkably successful, with the only major change in ~30 years of use being to move the hashed passwords to a file not readable by every user. But _any_ software gadget that collects a single world-wide password for each user cannot be trusted. We something akin to Vinge’s Secure Hardware Environment (SHE) postulated in “Rainbows End”. But computing is not headed in that direction. Instead, we are virtualizing all of our hardware. In 10 or 15 years, you won’t know if your CPU, RAM, and storage is real or virtual, local or in the cloud. The thing you touch with your hands and see with your eyes will be real, but it won’t contain 99% of your data.

    Comment by franl — 27 Nov 2008 @ 13:56

  14. […] after I posted this, Ben Laurie, who has forgotten more about security than I’ve ever known, posted about a similar issue on his blog. It’s worth a […]

    Pingback by I entered 37 passwords today - Glen Turpin: The Identity Question — 27 Nov 2008 @ 20:58

  15. The solution as I see it is mutual authentication.

    Users should not type passwords into any website until they have authenticated the website. We need to make this authentication a normal part of logging in so that users will do that as automatically as they currently do when typing in their passwords.

    SSL certs are designed to do this but they fail in a couple of significant ways. Extended SSL certificates fix some of the problems with SSL certificates but not all.

    What we really need is for people to eschew all CAs and to each start their own “chain of trust”. They should only trust websites they have personally verified or that people they trust have personally verified. I don’t trust Verisign so why should I trust any site they have signed the SSL cert for ? I have seen phishing sites with legitimate, CA signed certificates. If you start your own “chain of trust” then random phishing sites are somewhat less likely to be trusted.

    Ideally, the further down the chain a site is, the less I would trust it.

    If this were the standard mode for web browsers (no CAs, build-your-own chain of trust) then phishing would become much more difficult.

    Comment by Dave — 28 Nov 2008 @ 3:37

  16. […] a week ago, I posted about password usability. Somewhere in there I claimed that if passwords were unphishable, then you could use the same […]

    Pingback by Links » What Does “Unphishable” Mean? — 4 Dec 2008 @ 7:36

  17. Passwords, obviously dont’ scale. Passwords are not the solution.
    IMHO one possible solution would go though thinks like OpenID… and a strong authentication.
    Just one strong authentication and a single identity management system world-wide deployed.

    Authentication has to be easy, nice, confortable… or the users will bypass it as soon as they know how to do it. The process should maintain the KISS.

    Comment by Jaime — 28 Jan 2009 @ 16:54

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress