The first time such a user logs in, you can upgrade their hash to the latest scheme, so there's no extra work on later logins. Django, e.g., does just this, automatically.
https://docs.djangoproject.com/en/1.10/topics/auth/passwords...
I'm familiar with Django, and they happen to have some nice docs on both parts of the process: bulk upgrade to stronger scheme by wrapping [1] and individual upgrade on login [2]. But the technique isn't unique to Django.
[1]: https://docs.djangoproject.com/en/1.10/topics/auth/passwords... [2]: https://docs.djangoproject.com/en/1.10/topics/auth/passwords...
I'm curious about using two different algorithms for hashing at the same time would affect entropy. It could be that the original plain-text password has better entropy than the SHA1 hash (if that was your old hashing scheme) of the original password has.
Except you did this while the world was on fire, late on a Friday night, after a few beers, with management screaming down the phone. And you didn't check to make sure it didn't allow anyone to log into all effected users accounts with a null/empty password. Oooops...
(Been there, done that, made similarly stupid mistakes...)
This will make it impossible for those users to login. Also, if you are luck it won't take the rest of the service down with them, making it impossible for the other users to login too.
UPDATE users SET password=[generateRandomString] WHERE hashing_scheme='old';
?
The normal way of doing this is when the next time the user logs in, you use the old hashing scheme to check that the passwords match, if they do, you hash the password with the new hashing scheme and overwrite the old one with the new one. This is often coupled with invalidating all session tokens to force all users to login again (in order to speed up the process of migrating active users to the new hashing scheme).
The problem comes with the users that hasn't logged in for years, they still have their password hashed with the old scheme, but normally you would invalidate those hashes. That means getting rid of them completely so if a data breach would occur, their accounts doesn't have any hashes that could be attacked (UPDATE users SET password=null WHERE hashing_scheme='old'). From the users perspective, this would force them to reset (it's actually set now, not reset) their password via their email.