Isn't the point that the old hashes are out there somewhere and if cracked would reveal the plaintext password? This would then allow the attacker to access the compromised account since the password itself has not changed even if hashes are updated by doing newScheme(oldHash).
If your db has already been breached, it's too late to upgrade security on those hashes, true.
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.]
