For all sites that store memberships in a database, security and encryption of sensitive data is extremely important. The password being the obvious field that would need to be protected.  It’s surprising to see how many sites still use plain text passwords or one-way hashes for password storage and don’t realize how easy those are to hack.  Most systems implement a format known as the “one-way hash”. This means that for any input that set the password, the same input will always result in the same hash. But, there is no mathematical method of taking the resulting hash and determining what the original input was.  Using a system such as MD5, hashing the password “qwerty” will result in the string “d8578edf8458ce06fbc5bb76a58c5ca4″, but if I give this same string to people to reverse, it will be impossible for them to determine that the string comes from “password”.

How does this work from an application perspective? Lets assume your building out a membership provider, when you first go to create the user you will store the password as a hash – so instead of storing ‘qwerty’ you will store “d8578edf8458ce06fbc5bb76a58c5ca4″. When that user logs in next, they will enter their password, the system will hash this password using the same algorithm and compare the hashed values, there is no way for you to compare the actual passwords without hashing them. This is quickly becoming standard practice.

Now what if I wanted to break into this account? The fact that the same input always generates the same hash tag means I can build up a database of inputs and outputs and use that to attack an account, this is called using a ‘rainbow table’, a database of inputs/outputs used to determine a hashed password.  Rainbow tables are easily found on the internet, so this one-way hash is not as safe as once thought.  If your interested in learning more about rainbow tables, check out http://ophcrack.sourceforge.net/.

So what’s the best way of stoping rainbow table hacking? Salting. By generating a random “salt” for every user and attaching it to their passwords before hashing, you have made the rainbow tables ineffective. For example, the password ‘qwerty123′ becomes ‘qwerty123AS@#$fgr=’ and is then hashed into ’8a7bb436d4849395072483f7715b7edb’.  Because the salt generates a random string and each user in your database has a different salt value, you have effectively removed the threat of rainbow tables.

If you want to read more about the inner workings of rainbow tables, take a look at this post: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Article source: http://robbiemadan.com/2012/04/26/password-storage-101/