Wikipedia Account Request System – Password Storage

The current ACC system has some really useless bits which are hard to change, such as the password storage system. At the moment, the database is filled with “securely” stored passwords, such as “5f4dcc3b5aa765d61d8327deb882cf99”. Any quick Google search will quickly tell you exactly how the passwords are currently stored, a simple MD5 hash. This is quite clearly inadequate, so as part of the rewrite I’ve been aiming to store the passwords much more securely.

In all the examples, I’m going to use the password “password”.

At the moment, it’s simple to set a password, just store

md5("password");

into the database. It’s also simple to check the password, just check

md5($suppliedpassword) === $storedpassword

However, I was wanting to store the passwords with a salt, a different salt for each user – hence making cracking the MD5 hash much less feasible.

The function I’m now using to encrypt a password is this:

The $2$ at the front indicates the version of the password hash for later use. For a password “password” and a username “username”, this gives the encrypted result $2$8c6e7b658b4be4bb325870a1764ca4fb

When a password is checked, the code looks at the first three chars of the stored password, and determines if it matches $2$ or not. If it does, the provided password is encrypted with the new hashing function, and compared to the stored password. If they match, it’s the right password.

If the first three chars are not $2$, then it hashes the password using the old method, compares it, and if it matches, takes the provided password, hashes it with the new function, saves it to the database, and returns that it’s the right password.

This has the effect of being transparent to the user, but increasing the security of their password the first time they log in to the new system.