Correction: One problem with the argument I make below is that password storage length isn’t actually relevant if websites hash passwords instead of storing them in plaintext. So there’s no need to convince websites to store longer passwords: they should always be storing a fixed length hash to begin with. Thanks to @petrillic for bringing this mistake to my attention.

tl;dr: Every website I use seems to have a slightly different password policy. Here I review some very basic algebraic facts about randomly generated passwords. Based on those facts, I argue that every able-bodied website should adopt a few simple standards for user passwords, including the following rules:

1. Never prevent users from copying-and-pasting passwords.
2. Never restrict the length of passwords to anything lower than 40 characters. If you can, give users 255 characters to work with.
3. Never truncate the password that a user submits, because truncation will invalidate the user’s password. Do not lock users out of their accounts as a punishment for using strong passwords.
4. Never impose requirements on the types of characters used in passwords. Avoid encouraging l33t-speak passwords.

Introduction

After a long drive last week, I arrived home to find my phone filled with a long sequence of two-factor authentication tokens, which I took as evidence that someone had been trying to break into one of my accounts. After looking into the matter a bit, it became clear that the account to which access had been requested was one of a few accounts that shared a password with my old (and recently compromised) Adobe account. Thankfully, all of my important user accounts had two-factor authentication enabled and, as such, I have not found evidence of any successful intrusions. But the incident was nevertheless sufficient to inspire me to create unique passwords for every single website account that I have.

The Sad State of Website Password Standards

Unfortunately, the process of resetting my passwords en masse served mostly to remind me how poorly password security is managed by most websites. Every website seems to have its own set of ad hoc standards: some require passwords with a lot of different types of characters, whereas others require long passwords. Many websites will allow passwords to be 40 characters or longer, but a large number of websites impose puzzling restrictions on the maximum length of passwords.

In particular, one site, which will rename nameless to protect the guilty, required that passwords contain (a) 1 lowercase letter, (b) 1 uppercase letter, (c) 1 digit and (d) 1 special character – and simultaneously required that passwords not be longer than 10 characters.

The widespread requirement that users employ l33t-speak passwords puzzles me. A little bit of arithmetic makes it clear that a randomly generated password is enormously more likely to be secure if it consists of 40 randomly chosen lowercase characters than if it consists of 5 randomly chosen characters from the extended character set that contains lowercase characters, uppercase characters, digits and special characters. To see this, consider the number of distinct passwords generated by either (a) varying the diversity of the character set or (b) varying the length of the character set. Some sample calculations are shown below in which I consider four types of characters sets and randomly generated passwords of length 5, 10 and 20:

Why Does This Table Look Like This?

It’s hard not to be struck by the evidence the table above provides for the enormous superiority of long passwords over diverse passwords. When you go from the least diverse password to the most diverse password for a 5-character long password, you only go from 11881376 different passwords to 1934917632 passwords. If random guessing is feasible for one, it’s not that much harder for the other.

If, instead, you stick with only lowercase passwords and go from 5-characters to 20-characters, you go from 11881376 different passwords to 19928148895209409152340197376 passwords. Even if you could try out all of the smaller passwords in a second, we’d all be dead before you tried out all of the longer passwords.

To see why this happens, consider the number of distinct passwords you get when you either double the number of characters used or you double the length of the passwords generated. If you start with \(a\) different letters and use \(n\) of them, you’ll end up with \(a^n\) different passwords. And when you double the number of different letters, you increase this number from \(a^n\) to \((2a)^n = (2^n)(a^n)\).

If, instead, you double the length of the password, you increase \(a^n\) to \(a^{2n} = (a^n)^2 = (a^n)(a^n)\). This means that the superiority of using longer passwords over diverse passwords grows like \((\frac{a}{2})^n\), which is a huge number for even simple character sets that contain \(a\) different letters.

For example, if you’re looking at just lowercase characters for English, using a longer password instead of more diverse passwords is going to be \(13^n\) times better. In other words, going from a 10-character password to a 20-character password is more a billion times more secure than allowing both upper and lowercase letters in passwords that are always 10 characters long.

What About the Costs of Using Longer Passwords?

In response to my argument, one might ask: “won’t using longer passwords impose a serious storage cost on websites?"

Thankfully, the answer is, “not really”. Suppose you’re a wildly popular site and have a billion users. Then going from 10 character passwords to 255 characters will impose an additional storage cost of about 245 GB on you. Right now, getting a 512 GB hard drive costs about 50 dollars. So, the increased storage cost for most websites should be on the order of magnitude of 100 dollars. That seems quite affordable to me.

If Longer Passwords Are So Much Better, Why Don’t We Use Them?

Why did we wind up with a requirement for l33t-speak passwords and no ability to use long passwords? Probably because websites have found that users keep using simple dictionary words like “password” as their password, which you can prevent as long you force users to set up passwords that contain digits and other special characters. It’s hard to get users to employ truly random passwords, so it’s easier to impose some trivial amount of randomness by making them use “random” characters like @ and $.

A Plan for Action

Once we acknowledge the reasons why we wound up with the current set of heuristics for making passwords secure, we can move on and think how websites could do a better job in the future. The foremost step towards security, in my mind, is facilitating the use of high-quality password managers, like 1Password. You can make things easier for advanced users by adopting the following steps:

• Allow users to copy-and-paste their passwords from another source. When you force users to set up passwords they can easily type, you incentivize them to use short, memorable passwords. But short, memorable passwords are terrible passwords.
• Drop the unhelpful requirement that passwords contain a “diverse” set of characters. Adding a few special characters to a password does almost nothing to make it more secure. It’s not hard for a hacker to set up a dictionary of passwords that adds l33t-speak equivalents for every real English word.
• Impose a requirement that passwords be at least 12 characters long. Under no circumstances impose on users the requirement that passwords be shorter than 40 characters. Similarly, you should never truncate the password that a user submits to a length shorter than the string they submitted. Truncating passwords makes a password less secure and also locks the user out of their account.
• Offer to automatically generate a fully random password for every new user with an explanation of how this random password is better for security. Most users won’t take you up on the offer, but those that do will benefit substantially from the polite nudge towards using per-website unique passwords.