Single on OWASP vs NIST on password hashing

Use PBKDF2-HMAC-SHA-256 with at least 600,000 iterations, run through a FIPS 140-validated module. OWASP recommends exactly this when FIPS compliance is required. It also meets NIST SP 800-63B-4, which points to SP 800-132, the NIST document that defines PBKDF2. The two sources don't really conflict. NIST sets the rules and gives no iteration number, and OWASP fills in the settings.

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

• Order of preference: Argon2id first, with at least 19 MiB of memory, 2 iterations and 1 degree of parallelism. Use scrypt if Argon2id isn't available. Use bcrypt only on older systems where neither is available, with a work factor of 10 or more and a 72-byte password limit.
• For FIPS: the summary says to use PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations when FIPS-140 compliance is required. The PBKDF2 section adds that it "should be the preferred algorithm" in that case, because NIST SP 800-63B-4 permits it and FIPS-140 validated implementations exist.
• Other hash functions: with HMAC-SHA-512 it gives 220,000 iterations. HMAC-SHA-1 is for older systems only, citing NIST SP 800-131A Rev. 2.
• Pepper: it suggests adding a secret "pepper" as extra protection, stored apart from the database, for example in a secrets vault or hardware security module (HSM).

What NIST SP 800-63B-4 requires (https://pages.nist.gov/800-63-4/sp800-63b.html)
This is the current revision. It supersedes SP 800-63B, and the page I read is dated 26 August 2025.

• Must (SHALL):

  • Store passwords in a form that resists offline attacks.
  • Salt and hash them with a "suitable password hashing scheme".
  • Use a salt of at least 32 bits, and store the salt and the hash for each password.

• Should (SHOULD), so recommended but not mandatory:

  • Use an approved scheme from the latest SP 800-132 "or updated NIST guidelines on password hashing schemes". The reference list gives SP 800-132 as "Recommendation for Password-Based Key Derivation", the document that defines PBKDF2.
  • Set the cost factor as high as practical and raise it over time.
  • Store which scheme and cost factor each hash used.
  • Add one more keyed hashing or encryption step with a secret key, ideally kept in an HSM or similar protected hardware. If you do this, the key SHALL be generated by an approved random bit generator and stored separately from the hashes.
• No iteration number: Rev. 4 gives no minimum iteration count and does not name Argon2, scrypt or bcrypt.

What changed since the previous revision. Rev. 3 (https://pages.nist.gov/800-63-3/sp800-63b.html) said "A memory-hard function SHOULD be used". It named PBKDF2 and Balloon as examples and suggested "typically at least 10,000 iterations" for PBKDF2. Rev. 4 drops the memory-hard wording and the number. Older articles quoting "10,000 iterations" or "NIST wants memory-hard" are therefore out of date.

How to reconcile them. The only tension is that OWASP prefers memory-hard Argon2id, while NIST's approved route goes through SP 800-132, i.e. PBKDF2. OWASP itself resolves this by recommending PBKDF2 whenever FIPS is in scope. In practice:

1. Use PBKDF2-HMAC-SHA-256 from a FIPS 140-validated module, with at least 600,000 iterations, tuned upward to what your servers can handle. OWASP's general advice is to keep each hash under about one second.
2. Use a random salt of at least 32 bits per user, and store the algorithm and parameters with each hash so you can migrate later. One option OWASP describes is re-hashing with the new settings at the user's next login.
3. Add the keyed step with a secret key held in an HSM. NIST recommends it and OWASP's "post-hashing pepper" (an HMAC over the finished hash) is the same idea.
4. Don't use Argon2id, scrypt or bcrypt as the main scheme. That isn't because Rev. 4 forbids them, since its scheme requirement is a SHOULD. It's because they aren't the SP 800-132 approved scheme. That makes them hard to justify in a FIPS-scoped system.

Neither source says exactly what a FIPS audit will demand, so confirm module validation with your compliance team.

{"evidence": [
{"claim": "OWASP's default recommendation is Argon2id 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 scrypt as the fallback when Argon2id is unavailable.", "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 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": "For FIPS-140 compliance, OWASP recommends PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations.", "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 800-63B-4 or 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 suggests an optional 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 mandates salted hashing 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 an approved scheme from SP 800-132 SHOULD be used (a recommendation, not a SHALL).", "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 a high cost factor that increases over time, with no fixed number.", "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 recommends an additional keyed hashing or encryption step using a 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-132, which the requirement points to, is NIST's password-based key derivation recommendation.", "quote": "[SP800-132] Turan M, Barker E, Burr W, Chen L (2010) Recommendation for Password-Based Key Derivation.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "The previous revision (Rev. 3) recommended a memory-hard function, wording absent from Rev. 4.", "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": "Rev. 3 gave a typical minimum of 10,000 PBKDF2 iterations.", "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"}
]}