How long should a password be?

Large scale account hacks

When you hear about large numbers of accounts being stolen by a hack at some service provider, you are naturally concerned that the hacker might now have access to your account names and passwords. If the service was storing your actual passwords, that could indeed be the case. (As I've said before, if a service is storing your actual passwords, then they simply don't understand security or they have made some horrifically bad decisions.)

In fact, most services will store an encrypted (technically, a "hashed") form of your password. For example, if my password were "password" (and that's a very poor password, of course), then a service might store "5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8" which is the hash value that corresponds to that password. 1

What that means is that hackers do not get a list of user names and passwords. What they get is a list of usernames and password hashes.

And what's great about hashes is that you can calculate a hash from a password, but you cannot do the reverse - you cannot calculate the password from the hash.

As a result, one would think that by being hashed it'd be pretty unhackable, right?

Sadly, not so much.

Dictionary attacks

The most common type of password attack is simply a high-speed guessing game.

These attacks involve starting with an exhaustive list of possible words (including names, profanities, acronyms, and more) and perhaps a few rules to try interesting and common ways that people try to obfuscate words. They calculate the hash of each guess and if it matches what was found in the compromised database of account information that they're working against, they've figured out the password for that account.

As we'll see in a moment, it's easy for hackers to make an amazing number of guesses is a short amount of time.

That's why you're not using that kind of password, right?

That's why a password created from a totally random combination of characters is best; it forces hackers to move on to a true brute force attack to gain access.

Brute force attacks

Computers are fast. In fact, the computer on your desk is so fast that it's ability to do simple operations is measured in terms of billions of operations per second.

Creating a password hash is not a simple operation on purpose. However, it's still something that on most machines today can be done very quickly. Spread the work over a number of machines - perhaps a botnet - and the amount of processing power that can be thrown at password cracking is amazing.

The net impact is that it's now feasible to calculate the encrypted hash values for all possible eight-character passwords comprised of upper and lowercase alphabetic characters and digits.

62 possible characters (26 lower case, 26 upper case, 10 digits), in each of the eight positions gives us 221,919,451,578,0902, or over 221 trillion, combinations.3

This seems like a lot, until you realize that an off-line attack, which is easily performed once you've stolen a database of usernames and encrypted passwords, could be completed in a few hours. (This assumes technology which can "guess" something like 10 billion passwords per second - which for those performing these kinds of attacks is quite possible.)

It doesn't matter what your password is; if it's eight characters and is comprised of upper and lower case letters and numbers, the hackers now have it - even if it was hashed by the service that they stole it from.

Why 10 is better and 12 better still

As we've seen, eight-character passwords give you over 221 trillion combinations, which can be reasonably brute force guessed offline in hours.

Ten characters gives you over 850 quadrillion (853,058,371,866,181,866), and the offline brute force guessing time would be measured in months.

Twelve characters gives you over three sextillion (3,279,156,381,453,603,096,810), where the offline brute force guessing time would be measured in centuries.

That's why 12 is better than 10 and both are better than eight.

What about special characters?

I did leave out special characters, it's true.

Let's say that the system that you're using allows you to use any of 10 different "special characters" in addition to A-Z, a-z and 0-9. Now, instead of 62 characters, we have 72 possibilities per position.

That takes us to 700 trillion possibilities.

Compare that to sticking with the original 62 letters and numbers, but adding only a single character to make it a nine-character password.

That takes us to over 13 quadrillion possibilities.

Yes, adding and using special characters makes your password better, but significantly better yet is to simply add one more character.

So add two. Or four.

Shouldn't services fix this and do better?

Absolutely, they should. And many do.

As I've stated above, passwords shouldn't be kept in plain text anywhere by the service at all. And yet, some do.

There are techniques that make the brute force attacks significantly harder ... and yet many use techniques which are easier than the example I use above.

There are services that do a great job of keeping your information secure. There are also services that don't. The problem is that you really can't be certain which is which.

To be safe, you have to act like they're all at risk.

The bottom line

The bottom line for staying safe is simply this:

• Don't trust that the service that you're using is handling passwords properly. While many do, it's become painfully clear that many do not, and you won't know which kind that you're dealing with until it's too late.

• Use longer passwords; 10 characters minimum, 12 if at all possible.

• Use a different password for each different site login you have. That way a password compromised on one service won't give hackers access to everything else.

Even the best eight character passwords should no longer be considered secure. 10 is "good enough for now" but you really should consider moving to 12 for the long run.

•

1: For the technically curious, I'm using an un-salted sha256 as the hashing function here. That's technically better than md5 or sha1 that's commonly used.

2: OK, OK. Technically, the number is actually 221,919,451,578,090 + 3,579,345,993,194 + 57,731,386,986 + 931,151,402 + 15,018,570 + 242,234 + 3,844 + 62. When we also add in the possibilities of seven-character passwords, six, five, four, and so on. I'm not doing the math. It's around 225 trillion.

3: Many of the numbers and attack estimates here come from or are based on GRC.com's excellent Password Haystack page. Included there are links to an excellent Security Now! podcast segment discussing password length and how size really does matter.