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.
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';
?
I'm constantly switching between three OS, two browsers, different, sometimes auto-resetting computers, and it seems to be too much of a hassle.
How do I handle this? The only obvious option is a paper notebook.
I'd rather be on an Open Source password manager, but I've found the sync is always too painful to do yourself.
I find it also nicer than LastPass as it combines with the native password saving of FF/Chrome rather than the highjacking and restyling of input boxes that look like user/passwords done by LastPass.
[1]: https://github.com/pfn/passifox
[2]: https://chrome.google.com/webstore/detail/chromeipass/ompiailgknfdndiefoaoiligalphfdae/related?hl=en-USIt's probably fine so long as both your 'client' and 'server' are on localhost, but it'll probably never be secure if the server is exposed to the internet.
I use 1Password with the encrypted vault synced to Dropbox and it works wonderfully well. 1Password has native apps / browser extensions for all of those platforms (except Linux local app where they support and recommend using Wine).
But if you're trying to proactively strengthen your password hashes to make them more resistant in case of a future breach, this lets you do that with no inconvenience to your users.
Genuinely curious about the risks to upgrading password algorithms by wrapping the old hashes. (Because at least one major framework seems to suggest this approach.) Is this an absolute cryptographic disaster, or a tradeoff to weigh against other concerns, or ...?
The alternatives seem to be never upgrading your hash algorithms/iterations (which leaves old, weak hashes in your db -- clearly problematic in the event of a breach), or forcing userbase-wide password resets every time you upgrade (which could be a major inconvenience for the users, making it a reason to avoid or delay strengthening your password hashing -- also problematic).
[Just to be clear: I'm leaving all of this to my framework--I do know enough not to try to roll my own security. But I'd like to try to understand the decisions the framework maintainers make, and their potential ramifications.]
Doesn't help if $attacker has a list of breached oldScheme(password) hashes, and can crack useful numbers of passwords from you old weak oldScheme hash. They can still log into migrated accounts if they can reverse oldScheme into the characters of password.
If you're preemptively upgrading your password hashing aglo with the assumption that you have not (yet) been breached, that works (if your assumption is good). Once the oldScheme hashes are out there though, it's too late.
if date < '2016-01-01'
return newly_hashed == new_hash(old_hash($password))If a DB has an old hash, call it V1 obtained as H1(password), one can apply a newer hashing scheme H2(V1) and save V2. To avoid having two classes of users forever one can always apply H2(H1(password)) for new users.
It appears though, that this is not what dropbox did, when they changed the scheme to H2 in 2012, applying H2(password) for new users instead.
So for those users you'd have newScheme(oldScheme(password)). Then you could do a one-time migration of users with older scheme to increase the security to the new one.