Why are we concerned when we learn hashed passwords are compromised? They’re hashed, doesn’t that make them safe? Unfortunately no, many are stored in an unsalted hash. No, this isn’t a yummy breakfast food it’s a technical way of altering the original password to make it more difficult to use even if unhashed. Anyone managing identities for a web application should salt your passwords.
Most web applications use a one-way hash algorithm to store passwords, the password itself is never stored in the database; instead a hash representation is stored:
password = 5f4dcc3b5aa765d61d8327deb882cf99
After the account is created whenever the user types in their password, the value is hashed and checked against the hashed value in the database. If the two values match the authentication is successful.
This method is much preferred to storing passwords in plain text, but if your database in compromised it is still susceptible to routine password cracking techniques.
Take, for example, a traditional dictionary attack. All an attacker has to do is hash the words in the password cracking dictionary using the same algorithm. Then it is simply a matter of matching the resultant hashes against the hashes retrieved from the compromised site. An additional benefit of this method is that, because users tend to re-use passwords, the attacker now has password information for other sites as well.
The way to avoid this problem is to salt the passwords before they go into the database. Salting passwords is a method of security used primarily on UNIX systems that involves adding random characters to a password after the user creates it but before it is hashed. The entire salting process is invisible to the user. The additional characters make the passwords much more difficult to crack using traditional dictionary-style cracking methods, depending on the size of the salt.
Here is why. The random additional characters completely change the hash, so even if you have two identical passwords with salts that are only a single character off, you get two very different hashes:
password + s0mRIdlKvI = 60744474c3277428a8be861186e1e368
password + s1mRIdlKvI = 9dcf1d07827686b17946b6a70fe7f967
In the first example above, once an attacker figures out the hash for the password “password” he knows that every user in the database with the hash “5f4dcc3b5aa765d61d8327deb882cf99” has the same password.
With properly salted passwords even if the attacker manages to crack a password that hash will not match any of the other hashes in the database. Each password has to be cracked individually and it is a lot less likely that an attacker will be successful.
Note, the phrase above: properly salted. When the idea of salting passwords was introduced to UNIX systems 2 random characters were added to the passwords to create the salt. This might have been acceptable for small systems with few users, but for large databases it creates too many repetitive entries that make the password cracker’s job easier. Ideally, each user should be assigned a unique salt that changes when that user changes their password. This ensures that every hash in the database will be unique and it protects users who re-use their passwords across multiple sites.
By salting the passwords for your web-based application you are not only improving the security of your application but you are also improving the security of your users.