Security 104: Improper Password Storage

Now that you have a basic grounding in hashing and encryption, it’s time to get our hands dirty! This post is going to feature a bit of pseudocode for your enjoyment.

There used to be a time when it wasn’t outrageously irresponsible to simply convert a password to a different format for storage. Something like this, for example:

set password = binary(entered_password);

(… Actually, I lie. That’s always been bad. This is called “security by obscurity” and has never, ever, EVER been safe.)

Discounting the bad practice of simple format-shifting, up until a few years ago, it was acceptable to take a hash of the password and store that in the database, instead of storing the password itself:

set stored_password_hash = MD5(entered_password);

… When a user logs in, they aren’t verified by seeing if the entered password is the same as the stored one; they’re verified by seeing if the hash of the entered password is the same as the stored hash:

if MD5(entered_password) = stored_password_hash then login();

Unfortunately, with the advent of rainbow tables, this is almost as weak as storing the passwords in plain text! This is phenomenally bad, and could even constitute professional negligence on the part of the database admin.

Professional negligence, you say? What if you’re only running a free website? What if you’re not storing your users’ credit card details?

Yes, even then. I touched on this last week, but it’s worth reiterating: Even if all you’re storing is an email and a password, chances are extremely high that your users are using that same email and password everywhere. This means that if your database is stolen, you have potentially given the thieves access to your users’ email accounts, online banking, TradeMe accounts, etc. And this means that you have a duty of care to your users to protect them from any flow-on effects of your database being stolen away in the night.

So what we need now is a way to foil the power of rainbow tables. Since they’re precalculated tables, the easiest way to do this is to make rainbow tables uneconomical. That’s where the “salt” comes in, which will be explained next week.

———————————————————————————-

This post forms one part of our Security series. You can find links to the other editions here:

Security 101: What is Encryption?
Security 102: What is Hashing?
Security Interlude: The real-world difference between Hashing and Encryption
Security 103: Rainbow Tables
Security 104: Improper Password Storage
Security 105: Seasonings (or Salts and Peppers)
Security 106: The Importance of Key Stretching
Security 107: The Hashing Algorithm, and why Bcrypt is your best friend
Security 108: The Other Stuff

———————————————————————————-