How do I choose a good password?

The Rules: Old and New

For those with short attention spans, I'll start with what you need to do differently, beginning yesterday.

In the past, the traditional advice on passwords was:

• Eight characters long at a minimum
• Never use names or words, at least not without mangling them somehow
• Never use combinations of names or words, at least not without mangling them somehow
• Use a combination of upper and lowercase letters and digits
• Use at least one special character – something other than a letter or digit – if the system will let you

Those rules are no longer sufficient, and for all their complexity, they still leave you with a password that remains quite susceptible to certain types of compromises.

Instead:

• 12 characters long at a minimum
• Longer is always better
• Use a combination of upper and lowercase letters and digits
• Words aren't as evil as they once were, as long as the password is long enough
• Consider padding the password with a random character to make it longer

As you can see, there's a new emphasis on length.

If you remember nothing else from this article, size matters, longer is better.

The Dictionary Attack

One of the reasons that we've always been told to never use normal words (or common names) in passwords is that there are very simple attacks called "dictionary attacks" that simply try all words, or all combinations of words, one after the other until something works. (Many jump-start this process by starting with a list of known extremely common passwords.)

The Oxford dictionary tells us:

This suggests that there are, at the very least, a quarter of a million distinct English words...1

If we stick to all single case, then a program needs to try only 250,000 times 250,000 (62.5 million) times to be guaranteed to stumble onto a two-word password. I say "only" 62.5 million because to a computer running with speeds measured in billions of operations a second, that's nothing.

Yes, you can add names and random capitalization to the mix, and perhaps even insert digits, but even that slightly-obfuscated dictionary-based approach to password cracking remains something that is easily performed by today's technology.

It's also not necessary any more.

It's now quite possible for hackers to just try everything.

The Brute Force Attack

Let's say you've been really, really good and you have an eight-character password made up of completely random letters, numbers, and symbols.

Perhaps "7CxX&*Xf".

That's still a good password, but not a great password.

It's estimated that such a password could be cracked (offline) in a little over 18 hours.2

Doesn't matter that you didn't use words, or your name or anything else. Eight characters – 6,704,780,954,517,120 possible combinations and passwords – in less than a day.

Now, the most common response that I get when I throw out numbers like that is, "How can they try that many, that fast when I get locked out after three wrong attempts?"

Online Attacks

In the online scenario, it's very true that they can't try quite that fast, but they can still try fast enough for it to be a serious issue, particularly for dictionary attacks.

For example, I can envision a botnet that's not only sending spam, but is also performing a distributed dictionary attack against a set of email accounts at the same time. Slowly and from different locations, so as not to trip any limit filters, they try millions of passwords against hundreds of thousands of accounts.

Eventually, they'll hit pay dirt – especially if they try those "known most common" passwords first.

But surprisingly, that's not why eight characters is too short. A random eight-character password will probably protect you just fine from these types of online attacks.

It's the offline attack that you need to worry about, where your eight-character password – possibly any eight-character password – might be cracked in microseconds.

To understand how that can be, we need to start by understanding how passwords are stored. But first, we need to realize that guessing from the outside is only one way to get password information. Occasionally, it's something else.

The Database Breach

Every so often, we hear of an online service that has been hacked into and their database stolen.

What that typically means is that rather than trying to guess logins one at a time, a hacker has infiltrated the systems of the service and snatched a copy of some or all of the user accounts database.

As a result, they typically have:

• A list of all usernames or login IDs for that system
• A companion list of all passwords or password information for those login IDs
• Other stuff that the system may have stored for each user ID

No need to try guessing passwords slowly from the system's public-facing login; the hackers walk away with almost all of the information that they need in one fell swoop.

Now, note that I said "passwords or password information" above. Most systems do not store your password – they store something else.

Hash – Hold the Salt

Any system that can actually tell you what your password is should not be considered secure. Any system requiring security should never, ever actually store your password.

What they store instead is called a "hash" of the password.

A hash is a mathematical function that takes an arbitrary amount of text and computes from it a number. That number has the following characteristics:

• Any change, however small, in the data being hashed should result in a large change in the resulting hash.
• It should never be possible to reconstruct the original data from its hash value.
• It's not feasible to craft data that, when hashed, would generate a specific hash value.

So, instead of storing your password "iforgot", the system might instead store:

d9fd60a8cf992ec3d554ec2df8dd4cb345e77de7ecb4df4772920897b1d51bc5

That's the result of an "SHA 256" hashing function. Any time you give that function "iforgot," the result will be that number (which happens to be 256-bits long). What's important is that given only that number there's no feasible way to figure out what password caused it to be generated.

So, when you login, the system passes whatever you type in to the password field through the hashing function, and if the resulting number matches, then you must have typed in the correct password because it's the only thing that could have generated that number.3

All while not needing to store your actual password.

Now, as technology has grown more powerful, we've run into an interesting issue rendering even this nicely obscure means of storing passwords without actually storing passwords at risk.

Rainbow Tables (Sorry, no Unicorns)

Consider the eight-character password.

If the password that we're setting up allows each character to be any of 26 alphabetic upper and lower case characters, 10 digits, and 10 special characters, that's 72 possible characters in each position. If we have eight of those, that's 72 to the eighth power or 722,204,136,308,736 – 722 trillion – possibilities.

It sounds like an enormity, but with today's computational and storage power, it's possible to:

• Calculate all possible eight-character passwords

• Store in a table the password and its calculated hash value for all possible eight-character passwords

• "Crack" a password from that database you just stole by just looking up the hash value that you have in the table you created and fetching the corresponding password

That table, by the way, is called a "rainbow table."

In reality, hackers rarely need the entire table for various reasons; there are algorithmic shortcuts, not all hash functions are created equal, and so on and so on. And on top of that, we pick bad passwords, so a smaller table with just the hash values of lots and lots of common passwords is pretty darned useful to many hackers.

But even the worst-case scenario is quite do-able.

All because the hashing algorithms chosen are quite standard (trust me, you don't want to dream up your own – this is a place where you really want to leave the math involved to trained professionals – homebrew hashes are typically cracked algorithmically within seconds).

So, if your email service, your social media service, and your photo-sharing service and whatever else you happen to login into all use the same hashing algorithm, then they have all stored the exact same hash value for your password. If that table of password hashes is ever stolen, then a quick lookup in a rainbow table will retrieve the password which could then be used on any of those sites, even though they were never directly breached.

Now, as it turns out, there's a trivial way to stop that possibility.

Add seasoning.

The Salted Hash

"Salting" is a way to obscure the information stored in a service's password database.

Instead of computing the hash of a password, they instead add something to the password and hash the combination. Then, when the time comes to check that you've entered the right password, they take what you've typed in, add that same something to it, and hash the result. If the hash value matches, then the password is correct.

For example, perhaps I create my password as "iforgot". As we saw, that gave us an SHA256 hash of

d9fd60a8cf992ec3d554ec2df8dd4cb345e77de7ecb4df4772920897b1d51bc5

If, however, the system storing my password automatically adds "mypants" to every password and hashes the result – "iforgotmypants" – the hashed value is completely different.

9791d33a44b51d071a90cd246a3b8a4ca2491f9474ebd737bc137b82826c7e5d

When I come back to login and enter "iforgot," the system automatically adds "mypants" and hashes that, and the values match.

If the hash value is even in a rainbow table somewhere, it maps to "iforgotmypants" which is most decidedly not my password.

The item we add – the frivolous "mypants" in the example above – is known as "salt," as it changes the flavor of the result of the hash function. In reality, it wouldn't be anything so simple and it would vary from system to system (and if done really well, from account to account).

Now with all of that as backdrop, here's the kicker: you don't know how the services you use encode your password and too many do not use salt. In fact, a most recent breach at an extremely well-known large online service exposed the fact that they were not using salt to properly secure their database of hashed passwords. The passwords stolen could be easily looked up via available rainbow tables.

So, in the face of not knowing which services do password security right, how do you protect yourself?

Size Matters

The single most important thing that you can do to improve your password's security is to make it longer.

The longer the better, in fact.

Recall how I said an eight-character password gave us 722 trillion possible combinations? (722,204,136,308,736 to be exact).

A 12-character password results in 19,408,409,961,765,342,806,016 possible combinations.

There's no rainbow table big enough, and there won't be for quite some time. Short of storing your password unencrypted (which is a huge security no-no anyway), just about any hash will do, salted or not.

And, bonus: it's extremely unlikely that a dictionary attack will bother with the assorted combinations to eventually get to whatever it is you put in 12 characters.

Length doesn't imply complexity. There's a very strong argument that says:

****password****

is, in fact, a significantly more secure password than

7CxX&*Xf

Plus, it's easier to remember. (Although using normal words in this manner still makes me nervous for reasons I can't quite explain. )

In fact, even longer pass phrases – something like perhaps:

correct horse battery staple

are perhaps best of all. (With big a hat tip & propeller twirl to that great geeky web comic XKCD.)

The Bottom Line (this time at the bottom)

So, what should you do?

• Abandon eight-character passwords. They should no longer be considered secure.

• Create all new passwords 12 characters or longer. (You can make a password longer and more secure by adding repeating characters if you can't think of anything else.)

That's the bare minimum. For bonus points:

• Ask for your password (not a reset or "reminder") from your provider. If they can actually send you the password, complain loudly. They're doing security wrong. Consider leaving them; and at a minimum, use a unique password there that you use nowhere else.

• Never use the same password in more than one place. If, for some reason, an ID and password gets compromised at service "A", hackers will then run around to many, many other services – "B", "C", "D" and so on – and see if they can login with it. All too frequently, they can.

• Consider using a utility like LastPass or Roboform to remember all your different passwords for you.

And of course, keep your PC secure. No matter how strong your password, malware such as keyloggers can capture it; using an open Wifi hotspot without proper security could be the moral equivalent of writing your password on the wall for all to see.

1: How many words are there in the English language? – Oxford Dictionaries

2: Cracking time calculations are from Password Haystacks at GRC.com.

3: Technically, this is actually not true: it is possible that two inputs will generate the same hash. It is statistically, so extremely unlikely that it is in practice simply a non-issue. And as stated in the hashing algorithm requirements, there's no way to know how to pick an input value that would give you a specific hash value.