You must migrate a production user base from {bcrypt} to {argon2} with zero downtime and no forced password resets. How do you design this with Spring Security's password APIs?

## Why this is a design question, not a config toggle Passwords are one-way hashes: you **cannot** convert `{bcrypt}` hashes into `{argon2}` in bulk, because you don't have the plaintext. So any real migration must be **lazy** — it can only re-hash a user's password at the moment they log in and hand you the plaintext. Spring Security is built exactly for this via the `{id}` prefix + `upgradeEncoding` + `UserDetailsPasswordService`. ## Step 1 — Encoder that verifies old and encodes new ```java @Bean PasswordEncoder passwordEncoder() { String idForEncode = "argon2"; // new default Map<String, PasswordEncoder> encoders = new HashMap<>(); encoders.put("argon2", Argon2PasswordEncoder.defaultsForSpringSecurity_v5_8()); encoders.put("bcrypt", new BCryptPasswordEncoder()); // keep for verification return new DelegatingPasswordEncoder(idForEncode, encoders); } ``` Now `encode()` emits `{argon2}...`, while `matches()` still dispatches `{bcrypt}...` hashes to the BCrypt encoder. No existing login breaks. ## Step 2 — Make upgrades persist ```java @Service class ArgonMigratingPasswordService implements UserDetailsPasswordService { private final UserRepository repo; ArgonMigratingPasswordService(UserRepository repo) { this.repo = repo; } @Override public UserDetails updatePassword(UserDetails user, String newHash) { repo.updatePasswordHash(user.getUsername(), newHash); // now {argon2}... return User.withUserDetails(user).password(newHash).build(); } } ``` `DaoAuthenticationProvider` flow per login: 1. `matches(raw, "{bcrypt}...")` → success. 2. `upgradeEncoding("{bcrypt}...")` → `true` because the stored id ≠ `idForEncode` (`argon2`). 3. `encode(raw)` → `{argon2}...`; `updatePassword` persists it. User is now on Argon2, transparently, with no reset and no downtime. ## Step 3 — Handle the long tail (dormant accounts) Lazy migration only reaches users who log in. Design an explicit policy for the rest: - Track the count of remaining `{bcrypt}` hashes as a migration metric. - After a cutoff date, expire or force-reset accounts still on `{bcrypt}` (e.g., set an account flag that routes them through a reset flow). Only then can you safely drop the `bcrypt` entry from the map. ## Step 4 — Operational concerns - **Dependency**: `Argon2PasswordEncoder` needs **BouncyCastle** on the classpath. - **Parameter tuning**: Argon2 has three knobs — memory (KB), iterations (time), and parallelism. Benchmark on production-class hardware; memory-hardness is Argon2's main advantage over BCrypt but also means each hash consumes real RAM, which affects capacity planning and DoS surface. Use `Argon2id`. - **Rate limiting**: memory/CPU-heavy hashing amplifies login-endpoint DoS; keep throttling in place. - **Concurrency/idempotency**: two simultaneous logins may both attempt an update; the write must be safe to repeat. - **Auditing/CDC**: a hash column changing on login can trip change-data-capture or trigger alerts — coordinate with those systems. - **Rollback**: keep the `bcrypt` encoder in the map for the entire transition; removing it prematurely breaks any not-yet-migrated user. - **Testing**: add tests asserting that a stored `{bcrypt}` hash both authenticates and gets rewritten to `{argon2}` after login. ## Alternative framing to mention If you were *raising BCrypt cost* instead of switching algorithms, the same machinery applies — you'd keep `idForEncode = bcrypt` at the new strength, and `BCryptPasswordEncoder.upgradeEncoding` returns true for the lower-cost stored hashes. The `{id}`-based approach shines specifically when the algorithm itself changes.