Notifications
Clear all
Topic starter
01/07/2026 2:11 am
TL;DR: Password hash migration breaks the normal export-import model because hashes are one-way, so teams must preserve algorithm details, salt strategy, and parameters or silently break login flows, according to WorkOS. Silent rehashing is the practical path, but it only works when verification, rehashing, and legacy-hash sunset planning are handled with discipline.
NHIMG editorial — based on content published by WorkOS: Password hash migration: formats, salting, and silent rehashing
Questions worth separating out
Q: How should teams migrate password hashes without forcing a mass reset?
A: Use silent rehashing. Keep the original hash and its parameters intact, verify the user against that legacy format on next login, then immediately write a new hash using the target algorithm. The rehash must happen in the same request path, because passing plaintext into async systems creates a larger security problem than the migration itself.
Q: Why do password hash migrations fail even when the export looks complete?
A: They fail when the export omits the details needed for verification, such as algorithm variant, cost factors, salt location, or provider-specific parameters.
Q: What should security teams do when some users stay on legacy hashes for months?
A: Track legacy users by algorithm cohort and treat the remaining population as a governance metric, not an afterthought.
Practitioner guidance
- Map every hash cohort before migration Inventory each algorithm, iteration count, memory setting, and salt location for the source directory before any cutover work begins.
- Keep verification and rehashing in the login request Perform silent rehashing only after a successful password check and write the new hash in the same request path.
- Track legacy-hash tail risk by cohort Build a dashboard that shows how many users remain on each legacy format and how quickly each cohort is declining.
What's in the full article
WorkOS' full blog post covers the operational detail this post intentionally leaves for the source:
- Worked examples for bcrypt, scrypt, PBKDF2, and Argon2 export formats across common identity providers.
- Parameter handling details for salt, rounds, memory cost, and iteration count when the source system stores them separately.
- Implementation notes for same-request silent rehashing without passing plaintext into queues or background jobs.
- Practical guidance on how to treat dormant users, weak legacy formats, and sunset decisions as a migration programme.
👉 Read WorkOS' guide to password hash migration formats and silent rehashing →
Password hash migration: the governance gap teams miss?
Explore further
01/07/2026 2:33 am
Password hash migration is an IAM lifecycle problem, not a data export task. The article shows that password verification survives provider change only when teams preserve algorithm identity, salt handling, and hash parameters. That makes the migration a governed credential lifecycle event, not a simple schema move. The practitioner takeaway is that export validation must happen before cutover, not after users begin failing login.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: What is the difference between bcrypt, scrypt, PBKDF2, and Argon2 during migration?
A: They are all password-hash families, but they differ in how they store parameters and how much metadata must be preserved for verification. Some formats are self-describing, while others rely on separate fields or vendor-specific configuration. Migration success depends less on the brand of algorithm and more on whether all verification inputs survive the move.
👉 Read our full editorial: Password hash migration exposes the hidden risks in IAM cutovers
