I had an argument with a very smart, very capable server-side programmer a few years ago when I was integrating a project of my own with the Web services API (application programming interface) that he and his group had built. I was relying on his firm to manage the user session, including account information and password but no financial details, and I thought the password policy was rather elaborate, while also not encouraging good passwords.
I can’t remember the precise details, but I believe it involved the usual requirement of uppercase and lowercase characters, both a minimum and maximum length, and numerals and punctuation.
My missive to him noted, “Entropy is better served by a longer memorable password than complex ones.” His argument was that people chose terrible passwords already, so enforcing some minimal complexity was better than allowing anything. We left it at that.
Now the government’s got my back, and I hope it will change password policies in a way that benefits users and increases the difficult of cracking passwords, even when encrypted password files are leaked.
A new set of best practices in draft form from the National Institute of Standards and Technology (NIST) spells out what security researchers have been saying for years: letting people choose a long password they can memorize and don’t have to change for long periods of times is vastly more secure and sensible than the current guidelines at most websites.
What makes a password secure?
Password security derives from two related properties: They shouldn’t be easily guessed and they shouldn’t be easily broken through brute force. The more complex a password is, the more likely it can resist social engineering, where someone figures out the name of your first dog and your birth year, and computationally intensive chugging through all possible combinations.
Due to leaks of hundreds of millions of passwords over the last few years, those building password-cracking software have excellent insight into the typical sorts of passwords people compose, which means that brute force attacks no longer have to check for every possible combination of allowed characters, but can combine common dictionary words with known patterns.
When faced with a password requirement like the one above, most users take the easy path. Some sites spell out the requirements, while others only alert a user to what’s not right. And average people aren’t reading the fine print, in any case.
A person types, say, “rutabaga” (eight letters). It fails. They try, “Rutabaga” (a capital). Nope. “Rutabaga1”—needs punctuation! “Rutabaga1!” (the exclamation point being the shifted character on the 1 key of English and many other languages’ standard keyboards). Done.
Sites that show a red-to-green spectrum bar indicating how well your password meets the complexity test will show red for “rutabaga” and often a bright green for “Rutabaga1!” Even Apple’s password assistant agrees. But because of the knowledge of how people compose passwords, it’s easy for a cracker’s software to test the top 500,000 most commonly used words in English and add “1!” and “4$” and the like—trivial, fast, and predictable.
If this theoretical user had picked “Rutabaga pizza pickle factory” instead, the password difficulty jumps by many, many orders of magnitude. You might think that combining several words together that are all in the dictionary makes it easier to solve—but that’s only true for common phrases. I wouldn’t use five words in a row from “Moby-Dick,” but a random phrase I can remember with a picture in my head could survive the equivalent of millions of years of a high-end GPU-equipped computer chugging away. If I pick, “That time I walked down the street with a frog in my hand,” the universe will likely have completed its heat death before my email password gets broken under current computational theory.
This is well understood, but inertia is more powerful than entropy in this one case. People don’t want to change. The NIST report could help, even though it’s a set of recommendations, not rules.
What NIST says is the right path forward
As I’ve written many times before, all the conventional wisdom that circulates about what makes a strong password, often displayed in various forms on websites or in software that’s asking you create a password, is wrong and misguided. The NIST draft dispels a lot of those. (As a draft, elements could still change, but the group’s guidelines are absolutely in line with what security researchers and usability experts have been saying for years.)
There are many, many seemingly counter-intuitive elements to what you routinely see dictated to you when composing a password, but this advice to those asking users to come up with a secret include:
Make it easy for someone to come up with something they can memorize. That still means a minimum of 8 characters, but the draft suggests supporting at least 64, including all Unicode symbols and spaces. That allows for a memorable, long passphrase that’s also easy to type.
Fight fire with fire, checking potential user passwords against a subset of the well-known collection that crackers also use, and disallowing common ones. (Figuring out what “common” means and not frustrating users may be a challenge.) This is separate from disallowing the use of any words found in dictionaries, which has prevented people from picking memorable passphrases in the past.
Don’t routinely expire passwords. Passwords don’t go bad with age, only when they’re cracked. Forcing a password change makes it more likely someone picks a short and bad password, as well as writes it down and stores it in a form that’s more easily accessible to others.
Get rid of minimum complexity and rules, like requiring punctuation or a certain number of digits. That not so paradoxically makes people choose more easily cracked passwords.
Let people see or choose to see the password they’re typing in, although it shouldn’t remain onscreen indefinitely. Along with this, there’s advice about better designing the password selection interface, so that people can distinguish what they’re entering.
No password hints. These help with recovery, but resetting a password makes much more sense, as a hint dramatically weakens the password’s ability to resist guessing.
There are other more technical requirements, like requiring the use of salting, which mixes in a random value with each password before it passes through a cryptographic hash, that converts the starting text to a value that can’t be retrieved, only compared against. (That is, when you enter your password, the login process adds in the salt, then runs the combination though the same mathematical operations, and compares the results to see if they’re identical.)
Salting prevents two or more identical passwords being cracked simultaneously, because each encrypted password looks different: 20k32lj43lj4 + buffy encrypts differently than 4kj32l41gjjj + buffy. Even knowing a bunch of users might have picked “buffy” doesn’t help a cracker figure out which.
The recent crack of Dropbox that exposed 68 million of its accounts’ older passwords is less severe than it could be because the firm regularly improved how it encrypted its passwords. About half used salting.
The NIST draft also recommend using the same sort of hashing employed by iOS, LastPass, 1Password, and many others, where an operation is repeated many times—NIST suggests 10,000 cycles—which dramatically increases the computational burden for brute force cracking even the simplest password. The other half of the old Dropbox passwords were additionally protected by that approach.
The NIST sets standards and doesn’t have a regulatory role, so it can’t enforce policies. However, government agencies, private firms, and academic institutions often rely on NIST’s guidelines as a sensible shortcut to creating their own, while leaning on the authority of the government.
After the draft becomes final, it will be a joy to send links to websites, services, and apps that rely on urban password myths and suggest they consider getting up to date with the latest gold-standard thinking.