Plan-execute on OWASP vs NIST on password hashing

For a FIPS-bound service, the setting that meets both sources is PBKDF2-HMAC-SHA-256 with at least 600,000 iterations. It should run inside a FIPS 140-validated cryptographic module, use a unique random salt of at least 32 bits, and ideally add a secret key (a "pepper") held in an HSM. The two sources don't conflict. OWASP ranks Argon2id first in general but names PBKDF2 for FIPS cases. NIST's current revision requires a salted, cost-tuned scheme and points to its own approved-scheme publication rather than naming an algorithm.

1. What OWASP recommends

• Algorithm order: "Use Argon2id with a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism." If Argon2id is unavailable, use scrypt (N=2^17, r=8, p=1). bcrypt is for legacy systems only, with a work factor of at least 10 and a 72-byte input limit. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
• 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." The alternative with SHA-512 is 220,000 iterations. PBKDF2-HMAC-SHA1 (1,400,000 iterations) is for legacy use only and not for new systems. OWASP explains that PBKDF2 "is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations." https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
• Salt and pepper: Every password gets a unique salt. A pepper is optional defence in depth. It must be stored separately from the password database, in a secrets vault or HSM. If it is compromised, every affected user has to reset their password. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
• Upgrades: Raise the work factor over time and rehash each password when that user next logs in. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

2. What the current NIST SP 800-63B requires

• Which revision is current: Revision 4 (SP 800-63B-4). Its page says it "supersedes NIST Special Publication (SP) 800-63B" and carries an August 26, 2025 timestamp (https://pages.nist.gov/800-63-4/sp800-63b.html). The Rev 3 page says Rev 3 was superseded by SP 800-63-4 "as of August 1, 2025" (https://pages.nist.gov/800-63-3/sp800-63b.html). The NIST CSRC publication page returned a 404, so I couldn't check the status there.

• Password storage (Sec. 3.1.1.2):

  • Passwords must be stored "in a form that is resistant to offline attacks" and "salted and hashed using a suitable password hashing scheme."
  • The cost factor "SHOULD be as high as practical" and should rise over time.
  • "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 salt must be at least 32 bits. The salt and hash must both be stored. A record of the scheme and cost factor should be stored to allow migration.
  • Verifiers should add a keyed hash or encryption step with a secret key. That key must come from an approved random bit generator and must be stored separately from the hashes, preferably in an HSM or TEE.

  Source: https://pages.nist.gov/800-63-4/sp800-63b.html

• What Rev 4 doesn't say: I searched its text and found no mention of "PBKDF2", "bcrypt", "scrypt", "Balloon" or "memory-hard", and no iteration count. It neither endorses nor bans Argon2, scrypt or bcrypt. It defers to SP 800-132, which it lists as "Recommendation for Password-Based Key Derivation." https://pages.nist.gov/800-63-4/sp800-63b.html
• FIPS 140 (Sec. 2): Cryptography used by verifiers run by or for federal agencies at AAL1 and AAL2 "SHALL be validated to meet the requirements of [FIPS140] Level 1". That validation comes from implementations certified by the Cryptographic Module Validation Program (CMVP). https://pages.nist.gov/800-63-4/sp800-63b.html
• Rev 3, for comparison only (superseded): Rev 3 named PBKDF2 and Balloon as examples and said "A memory-hard function SHOULD be used." It suggested PBKDF2 iterations of "typically at least 10,000." https://pages.nist.gov/800-63-3/sp800-63b.html

3. How to reconcile them

• Algorithm: Use PBKDF2-HMAC-SHA-256 (≥600,000 iterations) or PBKDF2-HMAC-SHA-512 (≥220,000), from a FIPS 140-validated module.

  • This is OWASP's own FIPS branch.
  • It fits NIST's call for an approved scheme from SP 800-132 run in validated cryptography.

• NIST minimums:

  • a unique salt of at least 32 bits;
  • a cost factor set "as high as practical," with OWASP's figures as the floor;
  • the algorithm and cost factor stored with each hash, so passwords can be rehashed when the user logs in.
• Pepper: Add a secret-key step, ideally an HMAC with a key from an approved random bit generator, kept in an HSM or TEE. NIST says this SHOULD be done; OWASP treats it as optional. Plan for a pepper rotation forcing password resets, as OWASP warns.
• Argon2id: Keep it for non-FIPS deployments only.

4. Where the sources differ

• How specific they are: OWASP names algorithms and numbers. NIST Rev 4 names neither; it refers to SP 800-132 and only requires a cost factor that is "as high as practical."
• Memory-hard functions: OWASP still puts memory-hard Argon2id and scrypt first. Rev 4 dropped Rev 3's "memory-hard SHOULD" language.

• Unconfirmed claims:

  • I couldn't open SP 800-132 (404), so I haven't confirmed from NIST's own text which schemes are "approved." Whether Argon2, scrypt or bcrypt are FIPS-approved is unconfirmed by any page I fetched.
  • OWASP says HMAC-SHA-256 "is recommended by NIST" and that SP 800-63B-4 permits PBKDF2. Rev 4 itself never names PBKDF2 or HMAC-SHA-256, so those claims rest on its reference to SP 800-132.
• Pepper strength: NIST says verifiers SHOULD add a secret-key step. OWASP only says "consider" one and calls it defence in depth.

{"evidence": [
{"claim": "OWASP's default recommendation is Argon2id with at least 19 MiB memory, 2 iterations, parallelism 1.", "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-HMAC-SHA-256 with 600,000+ iterations 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 says PBKDF2 should be preferred where NIST SP 800-63B-4 / FIPS-140 apply.", "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 restricts bcrypt to legacy systems.", "quote": "The bcrypt password hashing function should only be used for password storage in legacy systems where Argon2 and scrypt are not available.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP says peppers must be stored separately from the password database.", "quote": "The pepper should be stored separately from the password database.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "SP 800-63B-4 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"},
{"claim": "Rev 3 was superseded by SP 800-63-4 as of August 1, 2025.", "quote": "This revision of NIST SP 800-63 has been superseded by NIST SP 800-63-4 as of August 1, 2025.", "url": "https://pages.nist.gov/800-63-3/sp800-63b.html"},
{"claim": "SP 800-63B-4 requires passwords to be salted and hashed with 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": "SP 800-63B-4 says the cost factor should be as high as practical.", "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": "SP 800-63B-4 defers algorithm choice to SP 800-132 or later NIST guidance on approved password hashing schemes.", "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": "SP 800-63B-4 requires a salt of at least 32 bits.", "quote": "The salt SHALL be at least 32 bits in length and chosen to minimize salt value collisions among stored hashes (i.e., to prevent multiple subscriber accounts from having the same hashed password).", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "SP 800-63B-4 recommends storing the scheme and cost factor so passwords can be migrated.", "quote": "A reference to the password hashing scheme used, including the cost factor, SHOULD be stored for each password to allow migration to new algorithms and work factors.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "SP 800-63B-4 recommends an additional keyed hash or encryption step with a verifier-only secret key.", "quote": "In addition, verifiers SHOULD perform an additional iteration of a keyed hashing or encryption operation using a secret key known only to the verifier.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "SP 800-63B-4 says the secret key should be kept in a hardware-protected area such as an HSM or TEE.", "quote": "It SHOULD be stored and used within a hardware-protected area, such as a hardware security module or trusted execution environment (TEE), such as a trusted platform module (TPM).", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "Federal verifiers at AAL2 must use FIPS 140 Level 1 validated cryptography.", "quote": "Cryptography used by verifiers operated by or on behalf of federal agencies at AAL2 SHALL be validated to meet the requirements of [FIPS140] Level 1 unless otherwise specified.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "Superseded Rev 3 recommended memory-hard functions.", "quote": "A memory-hard function SHOULD be used because it increases the cost of an attack.", "url": "https://pages.nist.gov/800-63-3/sp800-63b.html"},
{"claim": "Superseded Rev 3 suggested PBKDF2 iterations of typically at least 10,000.", "quote": "Therefore, the iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations.", "url": "https://pages.nist.gov/800-63-3/sp800-63b.html"}
]}