No-one will
have to reset their password. I'll just use md5(md5(password)
+ salt) for the new hash. The only thing users will notice is that their
stored cookies will stop working and they'll have to log in again.
I hope that wikipedia isn't currently storing raw passwords in the user
table. So the only way you could implement a resetles upgrade would be to
add a second password field.
If a user logs in with only the original password field set, you validate
against that and if okay, MD5 the password they entered and store it. After
about a year you remove the original password field (anyone who hasn't
logged in in that time deserves to have to do a password reset!). I used
this technique recently to upgrade from Unix CRYPT to MD5 for password
storage.
No, wikipedia isn't storing raw passwords, it's storing unsalted MD5 hashes.
But no second password field is required. We just concatenate the salt (in
this case, a concatenation of the user number and "wikipedia") to the
unsalted hash, then MD5 the whole lot again. Ordinary validation is then
conducted by calculating md5(md5(password) + salt), and comparing it with
the database value. You could have used this trick for your own upgrade. It
increases the CPU time needed for validation by a few microseconds, but one
could easily argue that's a good thing.
As an extra security measure, I realised that we could continue to use
md5(password) for our persistent session cookies. This means that a stolen
hash can no longer be used to log in.
By the way, the code is now written, and I've sent it to Brion.
-- Tim Starling.
_________________________________________________________________
Hotmail now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/hotmail_mobile.asp