Are You Adding Salt and Pepper to Your Security Recipe?

In my earlier days I always had a doubt about how the passwords are stored. When I studied Linux, I found that passwords are stored in /etc/shadow in a hashed format. What will happen if someone takes a copy of this file and try to recover the password. I asked this question to my instructor, but he told me that hashed passwords can’t be recovered and only root user will be able to access this file. I was aware of brute force and dictionary attacks at that time and using those methods, we won’t be able to crack a hashed password.

In 2012, I read about Linkedin password breach and was surprised to see that hashed passwords are getting cracked. How is this possible? The research went to find something known as Rainbow table.

More than 1000 GB data of hashed passwords were available to download and those were categorized as LM (Windows 2000, XP) , NTLM (Vista, Windows 7), MD5, SHA1 respectively. This means if we download this huge database, we can crack any hashed passwords. As I don’t have much space in my laptop and my external hard disk was almost full, I didn’t go for experimenting by downloading those. J

Linkedin hack was a wakeup call for everyone. Are there any options that would have prevented this hack? Yes, the mistake that Linkedin did was they didn’t salt their end user passwords. This means that if someone gets access to the hashed password database; they would be able to crack the password easily with the help of a rainbow table. It was also identified that there were lot of users using same password for their accounts. This is one of the areas where we should concentrate as a part of our password policies, not to accept common passwords like Password1, Password@123 or anything that has any relation to your username, family name, birthday or anything that has a relation with you. Good hackers won’t go to compute all hashed password’s, they will create some hashes related to the above listed category of passwords and the commonly used passwords to see whether they can crack it rather than going through the huge rainbow table.

After reading about Salt and Pepper, I was thinking..ehh..Adding Salt and Pepper..?? When we prepare curries, we add salt and pepper. Is that something similar in Cryptography?The same way like adding salt to curry, before getting cryptographically hashed, a string will be added to the password.  A new salt is generated for every password, and if multiple users have same password like “Password1”, they will have different hashes. This means no users will have the same hash if we add salt to it. Salt is usually stored as a plain text in the database with the encrypted passwords. So the attacker usually has access to the salt, but he needs to generate the pre-calculated table for each salt individually, that makes it very difficult to crack. However, as the salt is stored in the database with the password hash, a database compromise means losing both.

 We have the option of adding one salt for all the passwords which is of course the bad way of doing, it is recommended to add random salt for each password which makes things complex to a hacker.So most important thing to note here is that, random salt must be generated each time a user creates an account or changes his password. And don’t make the salt to short - longer the salt, harder to hack. If the salt is too short, an attacker can build a lookup table for every possible salt.

Pepper is normally added to the password in addition to the salt value. Functions are same as salt, however the pepper is held separately from the value to be hashed. The pepper is stored in the authentication code in your application and never gets to the database except as part of a hash.

Salting the passwords prevents hackers from using rainbow tables to gain access to your passwords quickly but with a sophisticated hardware/tool, still they can “brute force” to generate billions of hashes a second and compare them with the hashes you have stored in the database. Coming back to the same old topic, the most important topic is how we educate our users to construct effective strong passwords and should believe in Defence in Depth. First of all to gain access to our hashed password database, hackers should bypass the security controls in place and need to get an administrator access. Again it is not about having only controls, the weakest link in this Defence in Depth principle is the user himself, and it is important to educate him when he creates a password.

Authored by Aju Nair

Rate this article: 
Average: 3 (3 votes)
Article category: