Secure Password Storage

WebGUI currently stores user passwords as a plain MD5 hash of user input. MD5 is a one-way algorithm, meaning you can't derive the input from the output. Every time a user wishes to log into WebGUI, the password he tries is hashed and compared against the hashed value stored in the database. If the hashes match, the inputs must have matched.

Why do it this way? It seems like it would be easier to just compare the raw passwords, doesn't it? Of course, if someone ever got access to the database where your passwords were stored, he would then have access to all of your users' passwords. This would be a problem, since your users likely use the same password on other sites as well. If we hash the passwords, though, there is no way to retreive the passwords from the database. We still have a problem if someone has unauthorized access to our database, but let's assume for the sake of the discussion that we can't avoid that.

Unfortunately, it is possible for an attacker to recover the original cleartext (especially for shorter passwords, the shorter the easier) from a set of hashed using a precomputed dictionary of hashes, sometimes called a rainbow table. These are constructed by generating all or some combinations of characters and hashing the results, then comparing the hashes against those the attacker wishes to recover the cleartext from. In relatively short order (although with much more effort than if we had simply stored the cleartext), the attacker recovers the information he's after. WebGUI databases are currently vulnerable to this type of attack, although as we noted above - if the attacker has your database, you probably have larger problems.

Fortunately, there's a really easy way to severely limit the feasability of a rainbow table based attack. Instead of hashing the cleartext only, you randomly generate some random data (called 'salt') and hash it along with the cleartext, then store the salt for later use. When it comes time to check an attempted password, you combine the salt with the password in the same way.

The key here is that the salt will be different for each password. An attacker would have to generate a new rainbow table for each password he wanted to crack - a computationally prohibitive task. Combine this with a more computationally expensive hashing method (MD5 is very fast by design), and it quickly becomes more effort than it is worth to crack the password database in this fashion.

I have written up a request for enhancment to implement this kind of password hashing in WebGUI, and I think we can do it without breaking backwards compatibility. Pending approval, it should be relatively easy to implement. Please leave feedback on the RFE if you're interested in seeing this happen!

Note: For those of you interested in a more technical discussion of the issue see this article by Thomas Ptacek (a real security expert, which I am not!)