Single on OWASP vs NIST on password hashing

OWASP recommends Argon2id in general and PBKDF2 where FIPS-140 is required. NIST SP 800-63B-4 doesn't name an algorithm. It requires salted hashing with an approved scheme and defers the choice to SP 800-132. So a FIPS-bound team should use PBKDF2-HMAC-SHA-256 with a high iteration count. I read the NIST text on the 26 Aug 2025 page of the final SP 800-63B-4, which supersedes the earlier 800-63B.

OWASP Password Storage Cheat Sheet

• Its default advice is Argon2id with at least 19 MiB of memory, 2 iterations and 1 degree of parallelism. Its detailed list also gives equivalent trade-offs, such as 46 MiB with 1 iteration.
• If Argon2id isn't available, it says to use scrypt. The minimum is a CPU/memory cost of 2^17, a block size of 8 and a parallelization of 1.
• 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."
• It gives other PBKDF2 iteration counts: 220,000 for HMAC-SHA-512, and 1,400,000 for HMAC-SHA-1. It marks SHA-1 as legacy only, not for new systems.
• It recommends a unique salt per password. It also suggests an optional pepper stored separately, for example in a vault or HSM.
• Its stated rationale for PBKDF2 is: "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."

NIST SP 800-63B-4 (current revision)

• Verifiers must store passwords so they resist offline attacks: "Passwords SHALL be salted and hashed using a suitable password hashing scheme."
• A scheme takes a password, a salt and a cost factor. The cost factor "SHOULD be as high as practical without negatively impacting verifier performance" and should be increased over time.
• 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 salt must be at least 32 bits and chosen to minimize collisions between stored hashes. The salt and the hash must both be stored.
• A reference to the scheme and its cost factor should be stored with each password, so you can migrate later.
• Verifiers "SHOULD perform an additional iteration of a keyed hashing or encryption operation using a secret key known only to the verifier". The key must come from an approved random bit generator. It must be stored separately from the hashes, ideally in an HSM or TEE. This is NIST's version of a pepper.
• A search of the page found no occurrence of "PBKDF" or "key derivation function". SP 800-63B-4 therefore doesn't name PBKDF2 or Argon2id, and it doesn't set an iteration count.

Where the sources differ

• OWASP says NIST SP 800-63B-4 "permits" PBKDF2. The 800-63B-4 text I read doesn't name it. It only points to the approved schemes in SP 800-132, so OWASP's statement is an inference. I did not open SP 800-132, so I haven't confirmed that it lists PBKDF2.
• OWASP's general first choice, Argon2id, is not something 800-63B-4 prohibits or approves by name. NIST approval comes only through SP 800-132 or updated NIST guidance.

How to reconcile them

1. If the service really must meet FIPS or federal requirements, use OWASP's FIPS branch: PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations. Use a FIPS-140-validated cryptographic module. Argon2id is OWASP's general default, but it doesn't fit the FIPS case. It is not named in 800-63B-4, and I haven't confirmed it is approved under SP 800-132.
2. Meet the NIST "SHALL" requirements. Use a unique random salt of at least 32 bits (use 16 bytes or more in practice). Store the salt, the hash, and the scheme and cost factor for each password.
3. Add the keyed hash or pepper. NIST says SHOULD, and OWASP recommends it as defense in depth. Keep the key in an HSM or TEE, separate from the database.
4. Tune the iteration count to your server. NIST says as high as practical, and OWASP gives a floor of 600,000 for SHA-256. OWASP also warns that very high work factors open a denial-of-service risk, and suggests hashing take under a second. Raise the count over time, and re-hash at the next login.
5. If FIPS isn't actually mandatory for this service, OWASP's preferred Argon2id is the stronger choice. Check with your compliance owner which regime applies. The stored scheme metadata lets you migrate later.

{"evidence": [
{"claim": "OWASP recommends PBKDF2 with 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'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 justifies PBKDF2 for FIPS by asserting NIST permits it and FIPS-validated implementations exist", "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 lists PBKDF2 iteration counts per inner hash and marks SHA-1 as legacy only", "quote": "PBKDF2-HMAC-SHA256: 600,000 iterations (recommended)", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "NIST 800-63B-4 requires 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": "NIST defers the choice of approved scheme to SP 800-132 or updated NIST guidance, without naming an algorithm", "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 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 sets salt length and storage requirements", "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 to store the scheme and cost factor with each password 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/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"}
]}