Eh, why not just bcrypt the SHA1/MD5 hashes? Your auth check will just become bcrypt(SHA1(pass)) rather than bcrypt(pass). You can convert all passwords right away and I don't see any significant downside to it.
That would be fine if you wanted to retain the legacy hashing function. I was describing a migration from one hashing algorithm to another. You're describing modifying the existing hashing algorithm, which is something different.
It depends if your goal is to have security for everyone right away or if it's to only use one hashing function. I don't see anything wrong with a round of SHA1 in your setup, especially when it allows you to secure everyone's password immediately...
Will there not be a time lapse whilst you run bcrypt on all the existing hashes to update your users table? Given that bcrypt is intentionally 'slow', this might be a problem for applications with large numbers of users (albeit a one-off cost).
I agree that for small sites, changing the auth check and updating all the existing rows (and deleting/overwriting the old hashes) is probably the best solution though.
> Will there not be a time lapse whilst you run bcrypt on all the existing hashes to update your users table?
No, just SHA1 the password and check, and then bcrypt(SHA1) and check, until the encryption process finishes. Or just check the length, or store the hash type along with the hash, a la Django. These problems are trivial, really.
If you assume 6 million users and one second to compute a password hash, that's a couple of months on a single CPU. Takes a while, but no big deal, and it can proceed while your site stays live.
I like this idea for sites that e.g. use Microsoft ASP.NET Membership where all you can do is set a machineKey attribute about what kind of password hashing to use, and don't support any "old hash vs. new hash" alternatives for changing. Anyone know of an implementation that would do this and "drop in" to an existing ASP.NET site? Or pointers to how to approach developing this?
