Gated-execute on OWASP vs NIST on password hashing

I've read both documents and am writing up the answer now.

The two sources point the team to the same choice. The current NIST revision requires a salted, hashed password store using a "suitable password hashing scheme" and recommends (SHOULD, not SHALL) a scheme approved by SP 800-132. OWASP says that when FIPS‑140 compliance is required, PBKDF2 should be used. So the team should use PBKDF2‑HMAC‑SHA256 from a FIPS‑140‑validated module, with at least 600,000 iterations, a unique salt for each password, and ideally a secret pepper kept in an HSM. Argon2id is OWASP's general first choice, but OWASP itself sets it aside when FIPS validation is needed.

What OWASP recommends (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)

• Order of preference:

  1. Argon2id, at minimum 19 MiB of memory, 2 iterations and parallelism of 1.
  2. scrypt, if Argon2id isn't available.
  3. bcrypt, for legacy systems only, with a work factor of 10 or more and a 72‑byte input 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." OWASP gives two reasons: PBKDF2 is permitted by NIST SP 800‑63B‑4, and FIPS‑140‑validated implementations of it exist.
• Iteration counts: 600,000 for HMAC‑SHA256 and 220,000 for HMAC‑SHA512. HMAC‑SHA1 is "legacy only" and shouldn't be used for new systems.
• Other advice: use a unique salt per password, and consider a pepper as extra protection. A pepper is a secret key stored separately from the database, such as in a vault or HSM.
• Minor inconsistencies in the page: the introduction lists bcrypt next to Argon2id and PBKDF2 without qualification, but the summary limits it to legacy systems. It also says "Three hashing algorithms that should be considered" and then describes four.

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

• Status: this is the current revision (the page is dated August 2025) and it "supersedes NIST Special Publication (SP) 800-63B."

• Mandatory (SHALL):

  • Passwords must be stored in a form that resists offline attacks.
  • They must be "salted and hashed using a suitable password hashing scheme."
  • The salt must be at least 32 bits, and both the salt and the hash must be stored.

• Recommended (SHOULD):

  • Use an approved scheme from the latest SP 800‑132 or later NIST guidance.
  • Set the cost factor "as high as practical" and raise it over time.
  • Store the scheme and cost factor with each hash so you can migrate later.
  • Apply an extra keyed hashing or encryption step with a secret key. If you do this, the key SHALL be generated by an approved random bit generator and SHALL be stored separately from the hashes. It SHOULD be kept in an HSM or TEE.
• What it doesn't say: the section I read doesn't name a specific algorithm, and it doesn't mention memory‑hard functions.

How the NIST guidance changed between revisions
The older Revision 3 (https://pages.nist.gov/800-63-3/sp800-63b.html) named PBKDF2 and Balloon as examples. It said "A memory-hard function SHOULD be used" and suggested PBKDF2 iteration counts of "typically at least 10,000 iterations." Revision 4 drops all of that from the corresponding section, so older advice that cites a memory‑hard SHOULD or 10,000 iterations is out of date. OWASP's 600,000‑iteration figure is far stricter than the old NIST number.

How to reconcile them
The sources don't conflict. OWASP's general preference for Argon2id doesn't override NIST, and OWASP itself makes an exception for FIPS. For the federal requirement, the team should:

1. Use PBKDF2‑HMAC‑SHA256 from a FIPS‑140‑validated cryptographic module.
2. Set at least 600,000 iterations (OWASP), and keep it "as high as practical" and rising over time (NIST).
3. Use a unique salt of at least 32 bits for each password, stored with the hash.
4. Record the algorithm and cost factor with each hash.
5. Add a secret‑key pepper, generated by an approved random bit generator and kept in an HSM or TEE. Both sources recommend this.

There is one gap. I didn't open SP 800‑132 itself, so the claim that PBKDF2 is the scheme it approves comes from OWASP's statement and the older Revision 3 text, not from SP 800‑132 directly. NIST's "approved scheme" wording is also a SHOULD, so whether non‑approved schemes such as Argon2id are acceptable is a call for your FIPS compliance authority. The NIST text doesn't settle it.

{"evidence": [
{"claim": "OWASP's summary recommends Argon2id first, with minimum parameters.", "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 HMAC-SHA-256 and at least 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 justifies PBKDF2 for FIPS cases by citing NIST SP 800-63B-4 and FIPS-140-validated implementations.", "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 limits 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 suggests a pepper as defense in depth.", "quote": "Consider using a pepper to provide additional defense in depth (though alone, it provides no additional secure characteristics).", "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": "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 recommends (SHOULD) an approved scheme from SP 800-132 or later NIST guidance.", "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 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 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 an extra keyed hashing or encryption step with a secret key known only to the verifier.", "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": "The older Revision 3 named PBKDF2 and Balloon as examples and recommended a memory-hard function, language that Revision 4 dropped.", "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": "Revision 3 suggested PBKDF2 iteration counts of typically at least 10,000, far below OWASP's current figure.", "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"}
]}