Before we start, let’s get one thing straight: No password is uncrackable. Given enough time and resources, hackers can figure out your password. In this article, I’m going to cover the history of how sites store passwords and give you a brief explanation for how hackers bypass different storage types to get your passwords. Once you understand how passwords are stored, hacked, and cracked, you’ll be much better prepared to develop good, strong passwords.
So back in the Internet’s Iron Age (i.e., the mid 90s), sites wanted to personalize their user experiences, so they designed membership frameworks that allowed people to maintain virtual online personalities (a.k.a. user accounts). Essentially, this gave users their own little place on the Internet where they could maintain an identity, participate in discussions, and eventually purchase things.
The Internet was still relatively new at this point, so there really wasn’t a lot of hacking going on. People had dialup modems, most web pages were static, everything was slow, and there just wasn’t much reason to break into anything.
At this point in time, when you signed up for a user account, you’d enter your desired user name and password. Both were stored in a database file in plain text. The next time you logged in, the user name and password you entered were compared against the database. If they matched, the site let you in. If not, you had to try again.
This worked well for a while until people figured out how to break into these systems and steal the login databases. With this type of storage, a hacker only needs to steal the database to have access to all user names with their passwords.
Encryption is the process of converting a piece of data (like a password) into random characters so that it can’t be read by some rogue passer-by. Encryption is a computer’s version of a secret code, and that code is defined in an encryption key. Think of this key as a decoder ring that allows you to convert text into a code, and then convert the code back into the original text.
When you create an account, your password is encrypted by the key and the encrypted version is stored in the database. Next time you log in, your password is encrypted again, and compared to the encrypted version in the database. If they match, you’re in; if not, try again.
This sounds great, except for one thing: The key is likely stored in the same place as the password database. So if a hacker breaks into a server and finds both the password database and the encryption key, he can use the key to decrypt everything in the database. It’s much better in theory than it is in practice.
Want Hash with That?
The Achilles Heel of encryption is that it works in two directions: The same key used to encrypt the original data can be used to decrypt it back to its original form. Get the key, get the data. To make passwords more secure, they needed to develop an algorithm that only works in one direction. What they came up with is called hashing.
Hashing works just like encryption, except there is no way to reverse the encoding. So when you sign up for an account, your password is hashed into a string of random characters, and that hash is stored in the password database. Next time you log in, your password is hashed and compared to the hash in the database (sound familiar?). If it matches, you’re in; if not, try again.
Now, you might be thinking that if a hacker breaks into a server and steals your hashed password, they have no way to decode it back to its original form, so you’re in good shape. And you’d be wrong. Maybe.
It’s true that the hacker can’t do anything to extract the original password from the hash. But hackers are smart, and they’ve figured out a way to get around some of the hashes. There are only a handful of standard hash functions that companies use to create hashes. The hackers use the same hashing functions to convert passwords into hashes, then store these hashes in Hash Tables and Rainbow Tables. If the hackers get your hashed password, they compare the hash to the entries in the tables. If they find a match, they have your password.
They’ve been building these tables for a long time, and they basically act as a giant encyclopedia of password hashes. And the worst part about these tables is that they are generally published to the Web so that anyone can get access to them. This is why using dictionary words, common passwords, and names are a bad idea. Even seemingly random passwords might have already been hashed and added to the tables.
For example, in his fantastic article “Rainbow Hash Cracking,” (http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html) Jeff Atwood talks about a password cracking application called Ophcrack, which cracked the password “Fgpyyih804423” in 160 seconds. That’s less than three minutes, people. If your password is simpler than that, you’ve set yourself up to be hacked…and hacked fast.
Waitress, This Hash Needs Salt!
This is all pretty depressing, isn’t it? Developers keep coming up with new things to keep our data safe and hackers keep finding ways to defeat them. Don’t despair yet, though. Developers started adding another piece of data, known as a salt, to our hashes. A salt is a randomly generated piece of text that is prepended (added to the beginning of) the password, and the combination of the salt and password is then hashed.
Typically, a salt is generated for each user, and then again whenever the user changes the password. In this system, a hacker couldn’t really use Hash Tables or Rainbow Tables because they would have to contain each password hashed with every conceivable salt. And if the hacker does crack one password, the tables won’t help because it’s highly unlikely that two people with the same password would have the same salt…meaning that their hashes will be different.
When a password is stored as a salted hash, the only really feasible way for a hacker to crack it is by using a brute force attack. This is where a hacker downloads the data and tries to open it by attempting every key combination possible until they find the one that unlocks the data. Typically, the attack would start with all single-character passwords, move to all two-character passwords, and so on until the correct password is found. Of course, these attempts are not done by people, but by computers…computers that can make thousands (and potentially millions) of attempts per second.
This method of cracking passwords is infallable. Eventually, the computer will find the correct password. The good news is that if your password is strong enough, it will take the computer hundreds or thousands of years to get there.
You can breathe a sigh of relief now.
In Part III of this series, I’ll discuss how to develop a password that is strong enough to render a brute force attack useless and strategies for keeping yourself safer while online.
In the meantime, though, you should check out the following resources that shed more light on a lot of the things I mentioned:
- Lifehacker’s beautiful writeup about how passwords are stored on the Internet and whether or not password strength matters
- Rainbow Hash Cracking by Jeff Atwood
- Brute-Force Attacks: How All Encryption is Vulnerable by Chris Hoffman
- Salted Password Hashing by Defuse Security (highly technical, but amazing info)