Spicing Up Your Security: Salt and Pepper To Make Your Password Hash More Secure…

Today we live in an era where data is more valuable than life. Data security has become the chief aspect, with websites spending a large amount of their fortune just to keep their data safe. Ever wondered how your passwords are kept safe? Well, it is with salt and pepper.
Wait wait!!! I’m not talking about the salt and pepper you add to your seasoned breakfast. What I am talking about is the cryptographic salt and pepper that spice up your hash to make it next to impossible to decrypt.

So what exactly is happening here? What is a hash? What is salt? What is pepper? Why is it needed?

Internet is an enormous place where billions of people store their data, and privacy is the key factor any website can offer. To maintain this, a system of login credentials, i.e. username and password is used to keep the data safe. The password acts as a key, only people with the right password can access the data. This seems to be a secure system, security breaches now have to face an extra wall and crack the password to steal data. 

But, is it really so?

What if……. the website’s database containing all the users’ password is hacked????
That becomes a highway for the hackers to steal all data from any user they wish.

So the websites incorporate something called hashes. They are cryptographic functions that take in a string of characters and outputs a string of jumbled characters that looks nothing like the original string.
For example,

 password@123 -> 8e7152d0eb52c340579f2d70a28eaf1a2c5ba1c5

These hashing algorithms are written in such a way that even a small change in a single character gives a huge change in the output string. For example,

abcdef -> 1f8ac10f23c5b5bc1167bda84b833e5c057a77d2
abcdeg -> d8c771ae55b9a436034c64e1c0e0ff8b876a5faf

It is evident that changing the last ‘f’ into ‘g’ caused a huge change in the hash output, showing how untraceable these are.

{{CODEmyjscode}}

To the geeks reading this post, here is the JavaScript for the SHA-1 algorithm

A string, when fed to a hashing algorithm, always gives the same output, and these hashes are practically impossible to reverse. And… Eureka!!! Here is a perfect way for you to store the passwords.

The websites store the hash of your passwords, and when you login, they run your password through an algorithm and compare it with the stored hash. If the generated and one in the database match, then access is granted to the user. In the case of a database security breach, the passwords are still safe since there is no way the stealer can reverse the hashing algorithm to squeeze out the original password from the hash. So hashes can be called as the best way to protect your passwords.

Or at least theoretically…

Why is the spicing up needed???

Well, just now we saw that hashes are the “ULTIMATE” security level and are uncrackable, so you might be wondering why salt and pepper are needed.

The answer lies in human behaviour.

Humans are very predictable beings. We tend to create passwords based on familiar keywords, names or dates. Someone named Bob, whose birthday is on 10th June will most probably set his password as Bob@1006 or Bob@123 or 1006_Bob and so on. This gives an advantage to the hacker. Such information about a person is easy to gather.

The hacker can very easily create a list of all passwords that a person might possibly set. Trying out each and every password in the list gives a high probability of success of finding the right combination. Thus a person’s predictability makes him prone to the attack (This is called a dictionary attack).

Here is a list of the most common passwords of 2020. This just shows how easy it is to predict human behavior.

Furthermore, the hackers could also get the hashing algorithm into their hands, and create a table of the hashes of all such common passwords (called the rainbow table). Then just comparing their hash database with the rainbow table can give them the right combination.   

This is where the spicing up part enters. Salt is a random string of characters added to the input password before it is hashed. So if you enter the password as password@123, the website backend automatically changes it into something like &*(^z1password@123 and then hashes it. This makes the password more uncrackable.

This salt is stored in the database along with the hash itself like e64854077f4306d070790e521eadfad7de5ab9d7@r^$#.z1.
This might seem counterintuitive, but since every hash is stored with a different salt, to create a rainbow table the hacker needs to make different tables for different salts. This renders the rainbow table attack useless since salt makes a password longer and more complex to assume. But once one knows the salt, dictionary attacks are still a threat to the system.

So if salt is not enough, spice up your food with pepper *shrugs*.
Well, pepper is similar to salt but is generally shorter than a salt.
Waaaait a second… doesn’t that make it weaker than salt?

Simple answer- NO.

This is because the pepper is not stored at all. Not even the website backend knows what is the pepper string, or which position it is added to the password. When the user inputs the password to log in, the backend algorithm hashes all the possible pepper combination and checks each and every output against the stored hash. If one of them matches, then only the user is given access. This is entirely foolproof, no rainbow table can break this level of security, nor any dictionary attack, rendering all the efforts of a hacker useless.

So salt and pepper not only enhance your seasoned breakfast, but they also do spice up your security. But just as they say that good and evil are the two faces of the same coin, every development always brings some shortcoming to it. So, these hashing functions are also not fully foolproof. There is something called the pigeonhole principle which states that if n items are put into m containers, with n > m, then at least one container must contain more than one item. 

The hash created is only 40 characters long and contains only lower case letters and numbers, but the input string can be of any length and can include upper case and lower case letters, symbols and also numbers. Thus the number of possible input strings is more than the number of possible hash combinations. So ultimately two strings somewhere out there have their fates intertwined and are destined to have the same hash. Recently such a collision has been observed.

But it is not a matter of worry because such a collision is very rare and is very difficult to obtain. So right now none of you really need to worry about your passwords being stolen or hashes being broken and can sleep peacefully with your privacy assured.