Propose-select on OWASP vs NIST on password hashing

Summary. The two sources are compatible. OWASP's default is Argon2id, and its FIPS-specific advice is PBKDF2. NIST SP 800-63B-4 does not name an algorithm in the text I read. A team that must meet FIPS should use PBKDF2-HMAC-SHA-256 at OWASP's iteration count (at least 600,000), with NIST's storage rules on top. I read only the OWASP cheat sheet and the NIST SP 800-63-4 web rendering of 63B-4. I did not open SP 800-132 or any FIPS 140 validation material, so those points are flagged below as unverified.

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

• The general rule is that passwords "must be protected using strong, slow hashing algorithms such as Argon2id, bcrypt, or PBKDF2". Each password gets a unique salt.

• The preference order is:

  • Argon2id first, with at least 19 MiB of memory, 2 iterations and parallelism 1.
  • scrypt if Argon2id is unavailable.
  • bcrypt only for legacy systems, 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."

• The PBKDF2 section gives these iteration counts:

  • HMAC-SHA256: 600,000 (recommended).
  • HMAC-SHA512: 220,000.
  • HMAC-SHA1: 1,400,000, legacy only.
• It suggests an optional pepper, a secret kept outside the database (for example in a secrets vault or HSM), as defense in depth.
• It suggests keeping hashing under about one second, balancing security against login performance and denial-of-service risk.

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

• SP 800-63B-4 is the current revision. Its text says it supersedes the earlier SP 800-63B.

• The password-storage rules are:

  • Passwords SHALL be salted and hashed using a suitable password hashing scheme.
  • The salt SHALL be at least 32 bits and chosen to minimize collisions among stored hashes. The salt and the hash are both stored.
  • The cost factor SHOULD be as high as practical without hurting verifier performance, and SHOULD be increased over time.
  • A reference to the scheme and cost factor SHOULD be stored for each password, to allow migration.
  • "An approved password hashing scheme published in the latest revision of [SP800-132] or updated NIST guidelines on password hashing schemes SHOULD be used."
  • Verifiers SHOULD add an extra iteration of a keyed hash or encryption using a secret key known only to the verifier. The key comes from an approved random bit generator, is stored separately from the hashes, and should preferably be in an HSM or TEE.
• The page does not name PBKDF2, Argon2, bcrypt or scrypt, and it gives no iteration count. The reference list cites SP 800-132 as "Recommendation for Password-Based Key…". I did not open SP 800-132, so I have not verified which scheme it approves.

Where the sources differ

• OWASP says PBKDF2 "is permitted by NIST SP 800-63B-4". The 63B-4 text I read does not name PBKDF2. It only defers to SP 800-132 and future NIST guidance, so OWASP's claim rests on that indirect link.
• NIST's approved-scheme language is a SHOULD. The SHALLs are salting, hashing, the 32-bit minimum salt, and storing the salt and hash.
• The 600,000 figure is OWASP's, not NIST's.
• OWASP ranks Argon2id first. NIST does not rank algorithms in this text.

How to reconcile them

1. Use PBKDF2-HMAC-SHA-256 with at least 600,000 iterations for the FIPS-scoped service. This follows OWASP's FIPS exception and fits NIST's "approved scheme" language.
2. Run it in a FIPS 140-validated cryptographic module. OWASP's stated reason for preferring PBKDF2 is that it "has FIPS-140 validated implementations". I did not check validation databases, so confirm that your specific module is validated.
3. Follow NIST's storage rules. Use a unique random salt of at least 32 bits, and store the salt, the hash, and the scheme and cost factor in a versioned format.
4. Add a secret-key step. Apply an HMAC with a key held in an HSM or secrets vault, separate from the database. This satisfies NIST's keyed-hash SHOULD and matches OWASP's pepper.
5. Benchmark the iteration count so a hash takes under about a second and does not create a denial-of-service risk. Raise it over time and re-hash users at their next login.
6. Do not rely on Argon2id alone for the FIPS-scoped path unless your assessor accepts it. This is my inference. The NIST text I read does not list Argon2id, and I did not verify its FIPS status. If the service has non-FIPS tiers, Argon2id with OWASP's parameters is the better choice there.
7. Confirm with your compliance owner which obligations apply, and check the current SP 800-132 or newer NIST guidance. NIST 800-63B-4 covers federal digital identity, and FIPS 140 covers cryptographic module validation.

{"evidence": [
{"claim": "OWASP's general rule: passwords must be protected with strong, slow hashing algorithms (Argon2id, bcrypt, PBKDF2).", "quote": "Instead, they must be protected using strong, slow hashing algorithms such as Argon2id, bcrypt, or PBKDF2.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP's primary recommendation is Argon2id with minimum parameters of 19 MiB, 2 iterations and 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": "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 when FIPS-validated implementations are needed, and states that NIST SP 800-63B-4 permits it.", "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 PBKDF2-HMAC-SHA256 at 600,000 iterations as the recommended setting.", "quote": "PBKDF2-HMAC-SHA256: 600,000 iterations (recommended)", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "NIST 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": "NIST defers to approved schemes in SP 800-132 or updated NIST guidance, as a SHOULD, and does not name an algorithm in this text.", "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, with both salt and hash stored.", "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 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. It SHOULD be increased over time to account for increases in computing performance.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "NIST recommends storing a reference to 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 using 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": "SP 800-63B-4 supersedes the earlier SP 800-63B, so it is the current revision.", "quote": "This publication supersedes NIST Special Publication (SP) 800-63B.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"}
]}