3 ms·
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 has
by medmunds 10y ago
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.
- zepolen 10y agoYou have a lot to learn about security.
- medmunds 10y agoI'm certain you're right, and I'm here to learn. 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.]