Use a salt value when storing hashed passwords

[Nicklas Nordborg]

The current implementation store passwords to BASE as MD5 hash values. This is vulnerable to dictionary attacks since the same password always generate the same hash value. My suggestion is that we should use a random salt value that is combined with the password before the MD5 calculated. This will at least make dictionary attacks less attractive.

Changing this will create some backwards compatibility issues, so I hope this can be fixed in the 3.0 release. To minimize the problems here is what I suggest:

• For each existing account, the update generates a random salt (say 8 characters), and then calculate MD5(salt:MD5(password)). Since we already have the value for MD5(password) this is relatively easy.
• The SessionControl.login() method is changed accordingly in the non-encrypted case.
• The encrypted case also need to change, but this will also require changes in the client code. Instead of the old algorithm the client need to calculate: MD5(MD5(salt:MD5(password)):challenge. The hard part here is that the salt is unknown until we know which account the user is trying to login to. This means that when the user has filled in the login and password information, the client must ask the server (eg. with AJAX) for the salt value for the given login. It might even be better to let the client get both the salt and challenge with this request.
• If the user account doesn't exist, I think the server should respond with a random salt value.
• Changing the password for an account should also generate a new salt value. It will of course not be possible to change the salt values once everything is stored, since there is not enough information to calculate the new MD5.

[Nicklas Nordborg]

It seems like using a salt is not good enough. Brute-force attacks of MD5-hashes are possible today with moderate hardware even for relatively long passwords (<=7 characters). See ​http://codahale.com/how-to-safely-store-a-password/ for more information.

An alternative option is to use bcrypt (as discussed in the linked document). This would be a server-side encryption only which means that we must remove the 'Encrypt password' functionality from the web client. If good protection is needed against someone listening in on the server traffic we recommend that HTTPS is used instead.

And it may just be as good since the brute-force approach would be able to find the password from the current implementation relatively fast anyway.

[Nicklas Nordborg]

Replaced by #1641.