Why passwords suck

According to [my colleague], 50% of all support tickets at [large company] were related to passwords.

When we implement native login, we should not use passwords.

I’ll stipulate up-front that some people use 1Password and generate a 50 character random password for each site, and never re-use passwords, and never copy-paste them anywhere for friends, and never write them down on a post-it note. Those people are probably safe with passwords. Are you one of those people? You should be one of these people.

In the real world, people are not paranoid enough to do this. It is our job to provide a secure platform for our users. Passwords, as used by the general public, are insecure. We should design a system that has less opportunity for users to sabotage themselves.

The value of cracking a password is very high. Passwords are long-lived, so once you have access you typically have access for a long time. Password based systems also often allow you to login without notifying the account owner, so misuse may go undetected for a long time.

An illustration

Here’s a scenario of how things might escalate, illustrated by two characters, Andy and Ev. Andy has a Medium account, and Ev is the evildoer who wants to access Andy’s account. All the actions of Andy are absolutely things that happen in the real world all the time.

We start off with Medium allowing any password to be used.

Simple passwords

• Andy chooses “password”, or “12345678” because it’s easy to remember. Ev just attempts to log in with the most popular passwords, and is successful, probably in under five minutes, without any special hardware or software.
• Engineering mitigation: we build “max password attempts” functionality, which annoys Andy who genuinely forgets his password sometimes, and causes stress to User Happiness.
• Engineering mitigation: we require some complexity in our passwords. One uppercase, one lowercase, one number, one punctuation etc., that is not in the dictionary.

Requiring some complexity

• Andy chooses “M0nkey!”. (That’s a zero, not an “O”.) Ev does a modified dictionary attack with a botnet and probably logs in within a day or two, or else continually locks Andy out of his account by repeated failure.
• Engineering mitigation: we add “dictionary-like” protection to prevent passwords like the above. Users hate it and complain to User Happiness.
• Engineering mitigation: we build a “password-strength” meter to prevent passwords like the above. Users barely understand it, and are satisfied with a medium-strength password.

Too complex to remember

• Because Medium requires a gobbleydegook password, Andy writes his password down on a post-it. Ev walks by Andy’s desk, laughs maniacally, and logs in.
• Andy loses his post-it and is locked out of his account.
• Engineering mitigation: we add a “forgot password” mechanism.
• Because Andy needs to log in from multiple places, he emails his password to himself.

With a forgot password system, or users emailing themselves their own password, Medium can now only be as secure as the user’s email system. This is pretty much the upper limit for how secure we can make a password-only based system.

Third party failures

• Andy resets his password. He chooses the same one as for Slack, which also requires “complicated” passwords. Ev hacks Slack, and with a little effort decrypts the encrypted password associated with Andy’s email address. Ev reuses that on Medium, and logs in.