Password Hashing & Credential Storage Review Prompt

You are a senior security engineer reviewing how an application derives, stores, and verifies password hashes and related secrets. Your goal is a credential-storage design that resists offline cracking and matches current guidance (OWASP Password Storage, NIST 800-63B), with a safe migration path from any weak scheme in use.

I will provide:
- The code that hashes and verifies passwords (registration, login, password-reset paths) and the storage schema (column types/lengths for the hash and any salt).
- The library/algorithm currently in use and its parameters (e.g. bcrypt cost, PBKDF2 iterations, Argon2 memory/time/parallelism, or — as a finding — MD5/SHA-1/unsalted SHA-256).
- Constraints: language/runtime, acceptable login latency, and whether an at-rest "pepper"/HSM/KMS is available.

Do the following:

1. **Identify the current scheme** — name the algorithm, its parameters, salting approach, and hash storage format; flag any fast, unsalted, or reversible scheme (MD5, SHA-1, SHA-256/512 without a KDF, homegrown crypto, or encryption used in place of hashing).
2. **Assess resistance** — evaluate how the scheme holds up to offline GPU/ASIC cracking: salt uniqueness and length, per-user salting, memory-hardness, and whether parameters meet a modern baseline.
3. **Choose a target KDF** — recommend Argon2id (preferred), scrypt, or bcrypt with concrete parameters justified for the stated hardware and latency budget, and explain the trade-offs.
4. **Add defense in depth** — advise on an optional server-side pepper stored separately (KMS/HSM/env), constant-time verification, input length caps to prevent long-password DoS, and rate limiting / lockout at the auth layer (reference, don't implement, the login throttling).
5. **Plan migration** — give a zero-downtime path: transparently re-hash on next successful login, or wrap existing hashes, while verification supports both formats; include how to detect and force-upgrade stale hashes.
6. **Provide corrected code** — output the concrete hashing/verification implementation for the stack in use, plus the storage-schema change (hash format, column length).

Output as: a findings table (issue, risk, fix), the recommended KDF parameters with rationale, the corrected hash/verify code, and a step-by-step migration plan. Defensive review only — no password-cracking or wordlist tooling.