Security 105: Seasonings (or Salts and Peppers)

What on earth is a salt? And why are you using the word as if it’s a definite article instead of the normal “pass the salt, please”?

A salt is a randomly generated sequence of letters and numbers, which are coupled with another input (in this case the user’s password) and entered into a one-way formula (i.e. a hash is taken of the entire coupling). The result of this one-way formula is then stored in the database, in place of the password (and alongside the salt). This combination extends the users’ password to such a length that an effective rainbow table would need to be gigantic.

The hashing process then goes something like this (we’re using $p to indicate the users’ password):

To add even more complexity, and hence protection, each user is assigned a different, random salt. This means that a hacker would need to produce a different rainbow table for each user, in addition to the fact that an added salt means a password could be made up of literally trillions of possible combinations.

You may have also noticed something called a pepper in the table above. This is similar to a salt, except every user is assigned the same pepper and the pepper is not stored visibly in a database like a salt is. Its’ purpose is simply to further obfuscate what the hash relates to. In a very real way, it’s a security-by-obscurity layer (read: not very helpful), but if a hacker only manages to steal your database, the existence of the pepper won’t be obvious to them, and may be enough to foil their hunt for your users’ passwords.

For many purposes, we’ve now reached a sufficiently strong security layer. On some systems though, the salt (and therefore the resulting hash) is changed every time the user logs in, and the hashing process rerun so that the hashes remain fresh. This means that, even if someone has started building a rainbow table against that particular hash and salt, by the time they return, a new salt and hash have been generated. All of these factors combined mean that it is really quite impractical for someone to use a rainbow table-based attack.

Now we’re going to pause for a quick breather. I’ll be back next week with a bit more on when you need to really get security happening.

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

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

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