Salt & Pepper: Spice up your hash!

As much as I would love this to be about seasoning a beloved breakfast staple, there is something more to salt and pepper. Salt and pepper both refer to data that is generated and appended to some other data (in most cases a password) before its combined result is passed through a cryptographic hash function that outputs digested data that is nigh impossible to revert.

Whoa, whoa, whoa.. slow down!! What is happening here?! Let’s take a step back and talk about a cryptographic hash function and why it’s needed. The internet is one big digital world that stores a ton of information everywhere. And just like our real world some data needs to be securely locked up so only the right people can access it. We’re all used to having to log into a website with our username and a password. The password acts just like a key in that it provides only those with the correct key access to the secured data.

This door leads to all of my secrets.

Well how does a web server know that we’ve entered the correct password? It has to somehow verify what we’ve typed in. If they stored our username/password combination, that would work, wouldn’t it? Yes, it would absolutely work! But what happens if this data is somehow leaked or stolen by bad guys who want to hack the planet?!

Enter the cryptographic hash function that can scramble our data, a process referred to as hashing. Hashing involves taking in a string of data, running it through a mathematical algorithm, and outputting a slew of jumbled data that looks nothing like our original input. Our server will then store this hashed password and link it to the corresponding username. This hash function is referred to as a “one-way function” because it is infeasible to revert the process.

hash("password") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e7

It is important to note though that with the same hashing algorithm (and there are a few out there), the hashed output of the same string will be the same. This is how the server verifies that we have indeed provided the correct password. Because it has stored the hashed password it can run the hash algorithm on our input and compared to two hashed results.

Great! Now if our the database of user/password information is leaked, we’re safe! Unfortunately we’ve only added one layer of security to our sensitive data. The problem lies with how predictable humans are. We tend to create passwords based on memorable keywords, phrases, or numbers such that the password is easier to remember. Hackers can use this to their advantage by creating a list of passwords derived from common terms and checking each password at high rates to find the right combination (dictionary attack). The hackers can take this a step further if they know the hashing algorithm used to produce the hashed passwords. They can take their dictionary and pre-hash all of the passwords creating a new “rainbow table” for their attacks. Now all they need to do is check to see if any of the hashes of the rainbow table match with any of the hashed passwords in the database and they have our password.

Push It!

This is where salting comes into play. As mentioned earlier a salt is extra and unique data that is usually generated randomly and added to our password. The concatenated result is then hashed and stored. However, because the salt is unique the produced hash of the same password will not be the same.

hash(salt . "hello") = 58756879c05c68dfac9866712fad6a93f8146f337a78t
hash(salt . "hello") = c0e81794384491161f1777c232bc6bd9ec38f616560b1

Now seasoning your password with salt is a highly effective way to combat the rainbow table attack as the hackers will now have to spend an enormous amount of resources (mostly time in computing) to produced hashed results on a large scale. So what about pepper? Pepper works in a similar way to salt in that it is data that is also appended to data prior to being hashed. However, the main difference is that while salt is stored with the hashed value, the pepper value is hidden away from the hashed value. This adds the additional benefit that the pepper is not known to the attacker.

Although pepper may seem like just more security, it is not as commonly utilized as a salt. Accepted hashing algorithms such as PBKDF2 and bcrypt were designed to derive keys with salts only. Until algorithms are designed for use with peppers (and accepted by cryptographers) they avoid the peppers altogether. Furthermore the maintainability of peppers (as these hidden values must be stored somewhere) is called into question. Because hashes are a one-way function, the rotation of the pepper key creates an additional problem. A password hashed with a pepper relies on that original pepper in order to be validated. This precludes the rotation of the pepper key, a big security flaw! For now salt-seasoned hash is the way to go.