Do Password Rules Make Us Safer?
Passwords play a big role in protecting our data. Either a service provides a way to login with a password, or they provide a way to login with another service like email, Google, or Twitter and those services use passwords. Passwords are unavoidable and important. That means the passwords themselves need to be secure. Many services have password rules to ensure that people create secure passwords.
Most password rules do actually make a password more secure, but they add a negliible amount of extra security. They also create a sense of false security because people will think they can make shorter passwords if they have 1 of each:
- upper case letter
- lower case letter
- special character
To understand why, we need to understand what password entropy is. It’s mentioned in a lot of articles, but rarely explained. This one article provides a fairly in depth description despite the title. I’m going to try and be briefer.
In the most naive way of calculating entropy we need to see how many tries it would take to brute force a password. 26 letters in the English alphabet would be 26 tries for a 1 character password. Add upper case and lower case letters and we double that to 52 tries. Add 10 numbers and 33 special characters and we have 95 tries.
Each character adds to the number of tries exponentially. With just lower case letters, a 5 character password would be 26^5 (11.9 million) tries and a 10 character password would be 26^10 (141 trillion) tries. With all 4 password rules, a 5 character password would be 95^5 (7.7 billion). A 10 character password will now be 95^10 (5.9 x 10^19 or 1 million times 59 trillion)
So naively, the password rules do help. They seem to help a lot. For a 10 character password, our password rules increase the number of tries by 400,000 times. Let’s assume we can run 1 million guesses every second. A 10 character password with only lower case letters would take us 4.5 years to brute force. A 10 character password with all our password rules would take 1.9 million years to brute force. This is why many people believe the password rules make sense. The raw math shows that they help.
This is where we need to add a little humanity to our calculations. The XKCD comic is pointed because password rules make passwords harder to remember. Humans compensate by making them shorter. The problem is that exponential growth means longer passwords are better. With just 26 lower case letters, a 16 character password would be 26^16 or 4.3 x 10^22. That’s 1 billion times 43 trillion or about 1000 times more brute force tries than a 10 character password with all our password rules.
Not only do the password rules encourage smaller passwords, humans find ways to make them easier to remember. Most of us do so by putting the special characters in the beginning or the end. Or we make sensible replacements like replacing the letter O in a word with zero. Anyone who wants to break into your account will take these into consideration. Maybe only the first 2 and last 2 characters in your password have 95 possibilities to satisfy password rules, but every other letter is lower case. Maybe instead of 26 letters, they test for 26 letters + zero for 27 “letters” instead.
The XKCD comic has a great example of this. A 12 character password with password rules should be 95^12, which should take 17 billion years to crack at 1 million tries a second. Instead, it only takes 3 days at 1000 tries a second. At a million tries a second it would be 4.5 minutes before the password is cracked.
So at this point it sounds like length is what matters most. This is why I settled with a 16 character minimum for Maleega passwords. People can choose whatever password is easy for them to remember, it just has to be long.
What all this math fails to take into account though is how easy it is to get computing power. I just went from XKCD’s 1000 tries a second to 1 million tries a second as if it were nothing. That’s because it is nothing. Depending on how much your password is worth to someone (and for an email account that can be huge), someone can pay for enough cloud computing resources to run 1000, a million, or a billion attempts a second. It may cost a lot of money, but it isn’t out of the realm of possibility. If your data is worth it, someone will spend the money.
NOTE: there is also a concern on whether your system can handle that amount of traffic, but that is a different topic.
This leads to a very important question: how many times can a human being actually enter in a password? Yeah, should have been obvious from the start. Even 1 attempt a second is way too quick for an actual human being to make a password attempt. Limiting login attempts to 1 attempt a second will change the amount of time needed to crack the 12 character password from XKCD from 3 days at 1000 tries a second to over 10 years at 1 time a second. No amount of cloud computing resources can help someone trying to crack a password if your system creates an absolute limit of 1 attempt a second per user per IP address. You can make it even harder by locking the account from new login attempts after some number, say 10, of failed attempts.
Another consideration is the top million common passwords. These were retrieved from various password breaches over the years and are going to be used first when trying to break into a user’s account. Even at a slow rate of 1 attempt a second, a password can be cracked in 11 days. That’s assuming you’re using the last password in that list too. So everything on this list has to be banned. It isn’t sensible to have a user look at all these to see what isn’t allowed, but feedback can still be provided if the user tries to set a password with one on this list.
We are left with 3 sensible policies for passwords:
- a decent length. 16 characters minimum may even be a little too long and I may lower it for Maleega.
- a limit on the number of attempts that can be made
- a ban on commonly used passwords.
Most other password rules just serve to inconvenience users while providing little extra security. A few sensible policies will provide the lion’s share while making a user’s life easy. In the end that is what we want: maximize both our user’s security and convenience.