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

Short answer: Use PBKDF2-HMAC-SHA-256 with a FIPS 140-validated module. OWASP recommends Argon2id in general but points to PBKDF2 when FIPS compliance is required. The current NIST SP 800-63B (Revision 4) sets requirements on salting, cost factor and storage, and does not name a required algorithm in the passage I read.

What OWASP recommends

The OWASP Password Storage Cheat Sheet is at https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html. It gives an ordered list:

• Argon2id is first: "Use Argon2id with a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism."
• scrypt is the fallback if Argon2id is unavailable.
• bcrypt is for legacy systems only, with a work factor of 10 or more and a 72-byte password limit.
• For FIPS, it says: "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."

In its PBKDF2 section, OWASP gives these iteration counts:

• PBKDF2-HMAC-SHA256: 600,000 iterations (recommended).
• PBKDF2-HMAC-SHA512: 220,000 iterations.
• PBKDF2-HMAC-SHA1: 1,400,000 iterations, legacy only.

OWASP also states that "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."

The sheet recommends a unique random salt per password, and says libraries usually generate it for you. It also suggests an optional secret pepper, stored separately from the database (for example in a secrets vault or HSM). It recommends storing the algorithm and work factor with each hash so you can migrate later.

What NIST SP 800-63B requires

The page at https://pages.nist.gov/800-63-4/sp800-63b.html is titled "NIST SP 800-63B-4". It is dated 26 Aug 2025, and its abstract says "This publication supersedes NIST Special Publication (SP) 800-63B." So Revision 4 is the current version, and it replaces Revision 3. I did not check any NIST status page beyond this one.

The password-storage requirements in section 3.1.1.2 are:

• "Passwords SHALL be salted and hashed using a suitable password hashing scheme."
• The cost factor SHOULD be as high as practical without hurting verifier performance, and SHOULD be increased 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." This is a SHOULD, not a SHALL.
• "The salt SHALL be at least 32 bits in length", chosen to minimize collisions among stored hashes.
• The salt and hash SHALL both be stored. A reference to the scheme and cost factor SHOULD be stored too, so you can migrate to new algorithms and work factors.
• Verifiers SHOULD add a keyed hash or encryption step using a secret key. That key SHALL come from an approved random bit generator and SHALL be stored separately from the hashes. NIST says it SHOULD be kept in a hardware-protected area such as an HSM or TEE. This is NIST's equivalent of a pepper.

In the passage I read, 800-63B-4 does not name PBKDF2 or Argon2id. It defers to SP 800-132 or future NIST guidance. I did not open SP 800-132, so I cannot confirm from a source I read that PBKDF2 is the scheme it approves. OWASP asserts this ("permitted by NIST SP 800-63B-4"), but it is OWASP's statement, not NIST's. I also did not open any source on whether Argon2id is FIPS-approved, so I make no claim either way.

How to reconcile them (these steps are my inference, not stated by either source)

1. Do not choose Argon2id, scrypt or bcrypt as the primary scheme if the system must use FIPS-approved algorithms. OWASP itself points to PBKDF2 for that case, and NIST's "approved scheme" language points toward SP 800-132.
2. Use PBKDF2-HMAC-SHA-256 with at least 600,000 iterations, as OWASP recommends. Use a unique random salt per password. 16 bytes is a common choice and comfortably exceeds NIST's 32-bit minimum. Run it in a FIPS 140-validated cryptographic module.
3. Add NIST's keyed step: an HMAC with a secret key from an approved random bit generator, stored in an HSM or secrets vault. This also matches OWASP's pepper advice.
4. Store the scheme and cost factor with each hash. Re-tune the iteration count as hardware improves, and plan to move to Argon2id if your FIPS scope later allows it. Both sources support this kind of migration.
5. Confirm the details with your compliance or authorizing officer. FIPS applicability depends on the system's authorization boundary, and I did not verify that against any source.

{"evidence": [
{"claim": "OWASP's primary recommendation is Argon2id with a minimum configuration.", "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 states PBKDF2 is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations, so it is preferred when FIPS is 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 a lower iteration count for PBKDF2-HMAC-SHA512.", "quote": "PBKDF2-HMAC-SHA512: 220,000 iterations", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP advises an optional pepper stored separately from the database.", "quote": "Unlike a password salt, the pepper should not be public and should not be stored along with the generated hash.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "NIST SP 800-63B-4 supersedes the earlier SP 800-63B and is dated 26 Aug 2025.", "quote": "This publication supersedes NIST Special Publication (SP) 800-63B.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "NIST 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": "NIST defers to an approved scheme in SP 800-132 or updated NIST guidance, as a SHOULD, without naming an algorithm in this passage.", "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 and storage of both salt and 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 recommends storing the scheme and cost factor to allow migration.", "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": "NIST recommends an additional keyed hash or encryption step with a secret key stored separately, ideally in an HSM or TEE.", "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": "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"}
]}