Plan-execute-verify on OWASP vs NIST on password hashing

I've read both primary sources and am now writing the answer. I didn't open SP 800-132, so nothing below is cited to it.

OWASP Password Storage Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)

• First choice: Argon2id, with a minimum of 19 MiB of memory, 2 iterations and 1 degree of parallelism. The page lists equivalent trade-offs, such as m=47104, t=1, p=1.

• Fallbacks:

  • scrypt if Argon2id isn't available.
  • bcrypt only for legacy systems, with a work factor of at least 10 and a 72-byte password limit.

• FIPS case: "If FIPS-140 compliance is required, use PBKDF2 with a work factor of 600,000 or more and set with an internal hash function of HMAC-SHA-256." Its PBKDF2 section gives these iteration counts:

  • HMAC-SHA256: 600,000, marked as recommended.
  • HMAC-SHA512: 220,000.
  • HMAC-SHA1: 1,400,000, legacy only.
• Pepper: OWASP suggests considering one for defense in depth.
• Why PBKDF2: OWASP says PBKDF2 is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations.

NIST SP 800-63B-4 (https://pages.nist.gov/800-63-4/sp800-63b.html)

• Which revision: This is the current revision. The page's abstract says it "supersedes NIST Special Publication (SP) 800-63B", and the page carries a 26 Aug 2025 date.

• What it requires for passwords:

  • Verifiers SHALL store passwords in a form resistant to offline attacks.
  • Passwords SHALL be salted and hashed using a suitable password hashing scheme.
  • The salt SHALL be at least 32 bits and chosen to minimize collisions.
  • The salt and the hash SHALL both be stored.
  • The cost factor SHOULD be as high as practical and increased over time.
  • A reference to the scheme and cost factor SHOULD be stored, to allow migration.
• Approved schemes: It does not name an algorithm. It says "An approved password hashing scheme published in the latest revision of [SP800-132] or updated NIST guidelines on password hashing schemes SHOULD be used." The page contains no occurrence of "PBKDF", and its only hit for "Argon" is part of an unrelated word. So SP 800-63B-4 neither names PBKDF2 nor mentions Argon2. It points to SP 800-132, which I did not open.
• Keyed hash: Verifiers SHOULD add an extra keyed hash or encryption step using a secret key. That key SHALL come from an approved random bit generator and be stored separately from the hashes, ideally in an HSM or TEE. This is NIST's equivalent of OWASP's pepper.
• FIPS 140: "Cryptography used by verifiers operated by or on behalf of federal agencies at AAL1 SHALL be validated to meet the requirements of [FIPS140] Level 1." The AAL2 requirement is the same, "unless otherwise specified". AAL3 requires Level 1 or higher. The document says FIPS 140 requirements are met by cryptography validated under the CMVP.

Reconciling them

The two sources don't conflict. They answer different questions. OWASP's general preference is Argon2id. NIST sets requirements (salted, cost-based, approved scheme, FIPS-validated cryptography for federal verifiers) without naming Argon2id. OWASP itself carves out the FIPS case.

My recommendation, which is inference and not source text:

1. Use PBKDF2-HMAC-SHA256 or SHA-512 if the service falls under the federal FIPS requirement. Set at least OWASP's iteration counts (600,000 for SHA-256, 220,000 for SHA-512). Use a unique random salt of at least 32 bits, and larger in practice. Store the scheme and cost with each hash so you can migrate later.
2. Run it in a CMVP-validated cryptographic module. NIST's FIPS language is about validated cryptography for federal verifiers. Check that your library or HSM is validated, because "PBKDF2" alone doesn't satisfy that.
3. Add a secret-keyed step. NIST says SHOULD and OWASP says "consider". An HMAC with a key held in an HSM or secrets vault serves both.
4. Use Argon2id only where FIPS validation doesn't apply. Examples are components outside the FIPS boundary. Neither source says Argon2id is FIPS-approved, and NIST doesn't list it in this document. Confirm with your compliance assessor, and check the latest SP 800-132 or any newer NIST password-hashing guidance, since NIST defers to those.

One caveat: OWASP's iteration counts come from its own benchmarking, and NIST doesn't prescribe a number. Tune the count for your hardware, and raise it over time as NIST advises.

{"evidence": [
{"claim": "OWASP's first recommendation is Argon2id with a minimum configuration of 19 MiB memory, 2 iterations, 1 degree of parallelism.", "quote": "Use Argon2id with a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP recommends PBKDF2 with at least 600,000 iterations and HMAC-SHA-256 when FIPS-140 compliance is required.", "quote": "If FIPS-140 compliance is required, use PBKDF2 with a work factor of 600,000 or more and set with an internal hash function of HMAC-SHA-256.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP positions scrypt as the fallback when Argon2id is unavailable and bcrypt only for legacy systems.", "quote": "If Argon2id is not available, use scrypt with a minimum CPU/memory cost parameter of (2^17), a minimum block size of 8 (1024 bytes), and a parallelization parameter of 1.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP says PBKDF2 is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations, so it is preferred when those are required.", "quote": "Since PBKDF2 is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations, it should be the preferred algorithm when these are required.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP gives per-hash PBKDF2 iteration counts (600,000 for SHA-256, 220,000 for SHA-512).", "quote": "PBKDF2-HMAC-SHA512: 220,000 iterations", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "SP 800-63B-4 requires salted and hashed password storage using a suitable password hashing scheme.", "quote": "Passwords SHALL be salted and hashed using a suitable password hashing scheme.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "NIST does not name an algorithm but defers to approved schemes in SP 800-132 or updated NIST guidelines.", "quote": "An approved password hashing scheme published in the latest revision of [SP800-132] or updated NIST guidelines on password hashing schemes SHOULD be used.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "NIST requires a salt of at least 32 bits, stored along with the hash.", "quote": "The salt SHALL be at least 32 bits in length and chosen to minimize salt value collisions among stored hashes", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "NIST says the cost factor should be as high as practical and increased over time.", "quote": "The chosen cost factor SHOULD be as high as practical without negatively impacting verifier performance.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "NIST recommends an additional keyed hash/encryption iteration using a secret key stored separately, ideally in an HSM or TEE (analogous to a pepper).", "quote": "The secret key value SHALL be stored separately from the hashed passwords.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "Federal-agency verifiers must use FIPS 140 Level 1-validated cryptography even at AAL1.", "quote": "Cryptography used by verifiers operated by or on behalf of federal agencies at AAL1 SHALL be validated to meet the requirements of [FIPS140] Level 1.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "FIPS 140 requirements are satisfied by cryptography validated under the CMVP.", "quote": "Throughout this document, [FIPS140] requirements are satisfied by security technologies, products, and services that utilize implementations of cryptography validated by the Cryptography Module Validation Program [CMVP].", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "SP 800-63B-4 is the current revision and supersedes the earlier SP 800-63B.", "quote": "This publication supersedes NIST Special Publication (SP) 800-63B.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"}
]}