Who Salted my Hash?

April 9, 2019 | Posted by: Michael Gates

It seems that every week lately there is a story on the evening news about a database that has been breached and a warning issued that hackers may have your login credentials. Network information security doesn’t appear to be too healthy. One ingredient that can be used to improve the health of the system is salt. Yes, that’s right, I said salt. Believe it or not, salt can actually help to improve the health of information security. Here’s how.

As you’ve probably figured out, I’m not talking about our old friend sodium chloride – aka table salt. Rather, salting is a method that can help to improve the security of stored passwords. In order to validate the credentials of users attempting to access a system, the password must be stored for comparison. How passwords are stored can make or break access security for the system.

I think we can all agree that storing passwords in plain text is just a horrible idea. The next logical step would be to encrypt the stored passwords. That too, however, is problematic since a compromised encryption key can lead to easy access of all user credentials on the system. That is why a hashed version of the password is stored rather than the password itself.

Since hashes are a one-way function (the original input can’t be derived from the hash value), they are a good choice for storing passwords. When a user attempts to log in, the password they input is hashed and then compared against the stored hashed value. If the hash values match, then the user is granted access. In this way, the clear text version is never stored and remains inaccessible.

Storing hashed passwords is not infallible, however. Hackers implement a method often referred to as a rainbow table attack. With a rainbow table, the malicious actor will try as many possible variants of a password as possible and store the hashed values in a lookup file. If they are ever able to gain access to the database file on a system, they will compare the hashed versions to the ones stored in their rainbow table. If they find any matches, then they now know that user’s password.

Enter salt. A salt is a string of random characters. When a user sets their password on a system, a salt is generated, appended to the user’s password, and a hash value for that combination is stored along with the password. In the future when the user attempts to access the system, the salt is appended to the password they entered a hash value generated and compared to the stored value. The user is unaware that this is even happening and is not affected by the process. Since it is very difficult for hackers to account for every possible salt value in combination with every possible password, they can’t build a rainbow table with all the combinations.

There are a couple of key ideas to consider when using salts. First, the salt should never be reused and be unique to each user. If salts are reused, it again makes it more susceptible to a rainbow table attack. Secondly, the longer the salt the more secure the salted/hashed passwords. If the salt is too short, it’s easier for the hacker to build a rainbow table with all possible salt/password combinations. So, when considering the health of your network information security, always remember — the more salt, the better.