How Do I Choose a Good Password?

We frequently hear of major websites suffering data breaches that expose millions of user accounts and passwords to hackers.

This type of theft makes the concept of “good passwords” all that much more important to understand.

Moving target

What makes a password good constantly changes, sometimes in ways you wouldn’t expect.

To understand what makes a good password, we need to appreciate what makes passwords vulnerable, which means understanding a couple of the ways hackers hack.

Along the way, I’ll also discuss “hashes” and why a “salted hash” isn’t breakfast food, but a critically important approach websites should be using to keep track of your passwords.

And there will be rainbows.


I’m not a security guru.

The concepts I describe here aren’t intended to make you one, either. I’ve most definitely simplified — or over-simplified — to make a point or explain basic concepts. The devil is in the details, and you won’t find it here.

My goal is to explain how and why passwords are so darned important, why the password you think is strong enough probably isn’t, and what you need to do about it.

If you’re designing a website and looking for what you need to do to keep passwords secure, you’ve come to the wrong place.

If you’re an average computer user and just want to keep your online life secure, then follow the “New Rules” to the left and keep your computer safe.

If you’re curious as to how some of this stuff works at a high level … read on.

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, minimally
  • 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. Even if you carefully follow them all, you’re left with a password that remains susceptible to many types of compromises.

Now, the rules instead:

  • 12 characters long at a minimum. I recommend 16 and use 20 myself, when possible.
  • Longer is always better
  • Use a combination of upper and lowercase letters and digits
  • Words aren’t quite 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 even longer

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

If you remember nothing else from this article, let it be this: size matters. Longer is better.

The dictionary attack

One reason we were told never to use normal words (or common names) in passwords is that there are simple attacks called “dictionary attacks” that try all words, or all combinations of words, one after the other, until something works. Many attackers jump-start this process by starting with a list of known common passwords or words used in passwords.

The Oxford dictionary tells us:

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

If we stick to a single case (upper or lower, just not mixed), then a program needs to try only 250,000 x 250,000 (62.5 billion) times to be guaranteed to stumble onto a two-word password. I say “only” 62.5 billion 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 is easily performed by today’s technology.

It’s also not necessary anymore.

It’s now quite possible for hackers to try literally 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 a good password — perhaps the best you can do in eight characters — but it’s not a great password.

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

It 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 ‘ can be hacked in less than a day.

Now, the most common response I get is, “How can they try that many that fast when I get locked out after getting it wrong three times?”

Online attacks

The attacks I’ve described so far all involve the hacker having a stolen copy of some user account database that they can access on their own computer(s), offline. This allows them to attempt to crack it at extremely high speed — as fast as their computers allow.

In the online scenario — accessing the service directly attempting to break in — they can’t try nearly that fast. However, they can use other techniques to try fast enough for it to still be a serious issue.

For example, consider a botnet of hundreds of thousands of computers across the globe performing a distributed dictionary attack against a set of email accounts. Slowly, patiently, 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 “most common” passwords first.

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

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

To understand how that can be, we need to understand how passwords are stored. But first we need to realize that guessing from the outside is only one way to get password information, and it’s no longer the most common.

The database breach

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

What that usually 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-account database.

As a result, they typically have:

  • A list of all usernames or login IDs for that system
  • A companion list of 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 the information they need in one fell swoop.

Note I said “password information” above. Properly secured systems don’t store your password — they store something else.

Hash (hold the salt)

What a secure system stores instead of your password is called a “hash” of the password.

A hash is a mathematical function that takes an arbitrary amount of text and computes a number from it. 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:


That’s the result of an “SHA 256” hashing function. Any time you give that function “iforgot,” SHA 256 will return that number (which happens to be 256 bits long).

This is important: given only the hash, there’s no feasible way to figure out what password caused it to be generated. Hence, it’s often called a “one way” hash.

When you log in, the system passes whatever you type as your password 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 generate that number.

Your actual password is never stored.

Unfortunately, as technology has grown more powerful, we’ve run into an interesting issue that puts this technique at risk anyway.

Rainbow tables

Consider the eight-character password.

If the password we choose allows each character to be any of 26 alphabetic upper and lowercase 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, with a stolen database and an offline attack it’s possible to:

  • Calculate all possible eight-character passwords
  • Calculate the hash value for every possible eight-character password
  • Store that in a massive table

“Cracking” a password from a stolen database just requires looking up the hash value they got from the database and fetching the corresponding password. This type of table is called a “rainbow table.”

In reality, hackers rarely need the entire table. People tend to pick bad passwords, so a smaller table with the hash values of lots and lots of common passwords is enough to crack a huge number of accounts.

The hashing algorithms are often quite standard. So, if your email service, your social media service, your photo-sharing service, and whatever else you log into all use the same hashing algorithm, they’ll all store 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 your password. Then the hackers can try it at any of those other sites, even though they were never directly breached.

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 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


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


When I come back to log in and enter “iforgot,” the system automatically adds “mypants”, hashes that, and the values match.

If that hash value is ever in a rainbow table somewhere, it maps to “iforgotmypants”, which is most decidedly not my password.

The item we add — in the example above, the frivolous “mypants” — 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 recent breach at an extremely well-known large online service exposed the fact that they were not using salt at all to secure their database of hashed passwords. The stolen passwords could be easily looked up via rainbow tables.

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

Size matters

The single most important thing 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 for that, 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.

As a bonus, it’s extremely unlikely 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:


is, in fact, a significantly more secure password than


— plus it’s easier to remember. (Although using normal words in this manner still makes me nervous for reasons I can’t quite explain. Smile)

In fact, even longer passphrases — something like:

correct horse battery staple

are perhaps best of all. (With big a hat tip and 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. Period.
  • Make all 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:

  • Make your passwords 16 characters or longer. I use 20 characters myself whenever possible.
  • Use a password generator, such as that included with many password vaults, to make it a 16-character or longer random password.
  • Never use the same password in more than one place. If, for some reason, an ID and password gets compromised at service “A”, hackers then run around to many, many other services and see if they can log in with it. All too frequently, they can.
  • Consider using a password vault like LastPass to generate, remember, and fill in unique passwords for you.

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

Originally published as How Do I Choose a Good Password? on Ask Leo!