Video Screencast Help
Cyber Readiness and Response

Would You Care for Some Salt with Your Password?

Created: 08 Jun 2012 • 2 comments
uuallan's picture
+2 2 Votes
Login to vote

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.

Blog Entry Filed Under:

Comments 2 CommentsJump to latest comment

Clint M. Sand's picture

GREAT point Allan! It's been on my todo list for a while now to implement salted passwords.

I haven't found a scheme yet I've liked to ensure the salt is unique for each user which doesn't also mean ether storing the salt also in the database (pointless in this scenario...) or doing some basic encryption of another element (like a username) and using that as that particular user's password salt.

Where i'm leaning now is to have a static salt common across all users, and pick some amount of characters from their actual password to append to it to create the final salt.

For example: username = clint, password = I<3Symantec
Global site salt: Wldi23(32.2
dynamic salt offset = 3rd and forth character of actual password
then hash the combined string, so you'd end up with a hash of the following actually getting stored in the database:

MD5 ("Wldi23(32.2<3I<3Symantec") = 39b3812295950f556a99572fb5b97fd8

That gives me a dynamic password for every user but to comprimise it an attacker would have to know the global salt string (not in a database) plus the scheme of how it's dynamic, etc..

Any thoughts on that sort of thing?

Clint M. Sand, CISSP
Director, Security Strategy & Advisory
Security Business Practice

Login to vote
uuallan's picture

Thanks Clint!

I like this idea a lot and it gets around a problem with most complex salting schemes: you have to include the unique salt in the database.  In those cases the password database includes the salt value as well as the hashed password.  While it is exponetionally more difficult to crack these passwords than an unsalted password hash, you are still giving the attacker tools to do the job.

With your method you are using unique values for each salt, but you also are not storing those salts in the database, which improves the security of your password database.

Depending on the number of users you may want to add additional complexity by creating a number of site salts.  Store those salts in a seperate database (not on the same server as your username/password database) and in your username database reference a number, so that your authentication scripts know which salt to grab but it is not associated with a username.


Login to vote