My favorite way would be to store password information as a hash chain, so old users can be immediately upgraded to the latest method while new users just use the latest.
For example, Django currently stores its passwords in a single database column as
<algorithm>$<iterations>$<salt>$<hash>
So suppose we generalize that to a chain of one or more hash algorithms, with each output fed in as the password to the next, resulting in a final hash:
For new users, or if the old user finally came back and logged in with their correct password, you could then take the opportunity to write back a simplified version:
argon$<iterations>$<salt>|$<hash>
Iterations could be calibrated differently depending on the chain, if the earlier steps take enough time to matter.
As far as I can tell this is the best possible service you can offer to the users whose long-ago passwords you're storing, short of deleting their passwords entirely. Throwing away the earlier version and replacing it with the argon-wrapped version can't hurt them, and will almost certainly help.
(Usual caveats apply about not doing things that add complexity if you don't need it.)
To be specific about my claim: throwing away the earlier version and replacing it with the argon-wrapped version cannot make the user's original password easier to recover, because it adds no new information about the password. To convince yourself of that, imagine that there was some function `argon(hash)` that made the password easier to recover. Why wouldn't an attacker run that function themselves? In the very worst case a bad hash function that takes one second to run could only speed up the attacker's job by one second.
Wrapped hashes could have other side effects for probing non-hacked sites -- for example, attackers could probably figure out which chain a user has based on timing, which would let them narrow down a bit when the user last logged in. Hash chains could also theoretically reduce the total output space for the final hash, making it easier to brute force a password through the login form of a non-hacked site. I don't consider either of those likely to matter, but you might.
For example, Django currently stores its passwords in a single database column as
So suppose we generalize that to a chain of one or more hash algorithms, with each output fed in as the password to the next, resulting in a final hash: For example if you had a user who logged in way back in unsalted md5 days and never logged in again, you might end up with a chain like this: ... and then to upgrade to argon you would grab that string, shove the final hash through argon(), and write back: For new users, or if the old user finally came back and logged in with their correct password, you could then take the opportunity to write back a simplified version: Iterations could be calibrated differently depending on the chain, if the earlier steps take enough time to matter.As far as I can tell this is the best possible service you can offer to the users whose long-ago passwords you're storing, short of deleting their passwords entirely. Throwing away the earlier version and replacing it with the argon-wrapped version can't hurt them, and will almost certainly help.
(Usual caveats apply about not doing things that add complexity if you don't need it.)