Lesson 3.15: Migrating password hashes
Most user databases contain a history of hashing decisions: unsalted SHA-1 from the first version, MD5-crypt from a migration, SHA-512-crypt, bcrypt, and maybe some Argon2id. You can't convert a hash into a better one without the password, so migration happens in steps: rehash when the user next logs in, and force a reset where the old hash is too weak to keep. In the lab you classify Northwind's hash formats, prove a service account uses a breached password by recomputing its SHA-512-crypt hash with openssl, check Argon2id parameters against OWASP's guidance, and write the migration policy.
16 min
You will learn to
- Recognise hash formats ($1$, $5$, $6$, $2y$, $argon2id$, unsalted)
- Recompute a crypt hash with openssl passwd
- Check Argon2id parameters
- Plan rehash-on-login and forced resets
- Write a hashing policy
Key terms
- Modular crypt format
- $id$salt$hash strings that name their scheme: $1$ MD5, $5$/$6$ SHA-crypt, $2y$ bcrypt, $argon2id$.
- Argon2id
- Memory-hard password hashing, winner of the Password Hashing Competition (RFC 9106).
- Rehash on login
- After a successful login, store a new hash with the current scheme if the old one is weaker.
- Hash wrapping
- Applying a strong hash to an old hash (argon2id(sha1(pw))) to protect it at once.
- Work factor
- The cost parameters (rounds, memory, time) that make each guess expensive.
← How systems store passwords · All lessons · Talking past the help desk: MFA reset attacks →