These days, it’s not so much a question of whether you’ll get hacked as when. More likely than not, at some point during the life of your organization, a hacker will gain access to your password database. If that happens, how much do you need to panic? That depends on how your passwords are stored.
The simplest but dangerously insecure approach to password storage is to use plain text. Here, if someone’s password is “pass123,” that’s written directly into your database. If the database becomes compromised, you’re up a creek without a paddle. The only solution is to change all passwords immediately, and hope the cracker didn’t get anything important.
So, you’ve decide you’re not going to store any plain passwords. Good for you! What do you store? You still have to store something for users to authenticate against. There are two things you can do to your passwords which, in combination, make them much harder to crack: hashing and salting.
First, hashing: hashing is the use of a complicated algorithm to transform a simple password like “pass123″ into something non-obvious, like “vc7K8529.” The important characteristic of the hash is that it’s easy to do going forwards, but very difficult to do going backwards. Something simple like transposing every letter and number by one step isn’t going to cut it; it’s too easy to go backwards from “qbtt234″ to “pass123.” Several hashing algorithms have been developed over the years. You should usually choose the newest one.
However, hashing passwords alone isn’t enough. Hackers are aware of many hashing algorithms, and they keep lists, called rainbow tables, of common hashes of common passwords. They’ve got most if not all the hashes for “pass123″ and similarly common passwords. So, if any one of those hashes appears in the list, the entire hashing scheme becomes known, and all the other more unusual passwords become much more easily compromised as well.
That’s where salting comes in. You can’t force users to come up with good passwords on their own – there’s always going to be someone trying to get away with “pass123.” What you can do is make the password better on the machine level. You can add some extra bits to it, called a “salt.” For example, “pass123″ becomes “8Ytu9j06pass123.” Much better! You do have to store the salt in your database somewhere, because your user doesn’t have that part memorized. If your system is compromised, that means the salt gets compromised as well. However, the benefit is this: when you run that salted password through a hashing algorithm, it produces a different hash than the one produced by “pass123″ on its own. That means that rainbow tables have to contain thousands more entries for each common password plus all the salt possibilities for each common password, making them a much less effective tool for password cracking.
In conclusion, if you have to store passwords, always make sure they’re hashed and salted. You should still have everyone change their passwords if you get hacked, but this method should give you a bit more time and security.
