Gated-execute on OWASP vs NIST on password hashing

The OWASP cheat sheet recommends Argon2id in general and PBKDF2 when FIPS-140 compliance is required. NIST SP 800-63B-4 requires salted hashing with an approved scheme but names no algorithm. For a FIPS-bound service, that means PBKDF2.

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

• The default order is:

  • Argon2id, at minimum 19 MiB of memory, 2 iterations and 1 degree of parallelism.
  • scrypt if Argon2id is unavailable.
  • bcrypt only for legacy systems.
• For FIPS, it says to use PBKDF2 with a work factor of 600,000 or more and HMAC-SHA-256 as the internal hash.

• The detailed PBKDF2 section lists these iteration counts:

  • PBKDF2-HMAC-SHA256: 600,000, which it marks as recommended.
  • PBKDF2-HMAC-SHA512: 220,000.
  • PBKDF2-HMAC-SHA1: 1,400,000, for legacy use only.
• It also suggests an optional pepper for defense in depth. The pepper should be stored separately from the database, for example in a vault or HSM.
• It says PBKDF2 "is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations."

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

• Section 3.1.1.2 requires that "Passwords SHALL be salted and hashed using a suitable password hashing scheme."
• The salt must be at least 32 bits and chosen to minimize collisions. Both the salt and the hash must be stored.
• The cost factor "SHOULD be as high as practical without negatively impacting verifier performance" and should be raised over time.
• It says an approved scheme from the latest revision of SP 800-132, or updated NIST guidance, SHOULD be used. It does not name PBKDF2, Argon2id or any other algorithm itself.
• It says verifiers SHOULD apply an extra keyed-hash or encryption step using a secret key. That key must come from an approved random bit generator and be stored separately from the hashes, ideally in an HSM or TEE. This works like OWASP's pepper.
• It also says the scheme reference and cost factor SHOULD be stored per password so you can migrate later.
• I read only the password-storage passage of NIST's document, not the whole thing. I did not open SP 800-132 or any FIPS 140 validation material, so the point that PBKDF2 is that document's approved scheme comes from OWASP's wording plus my own background knowledge.

One difference between the sources. OWASP says PBKDF2 "is permitted by NIST SP 800-63B-4." In the passage I read, NIST only points to SP 800-132 and does not name PBKDF2. The two are compatible, but the link to PBKDF2 goes through SP 800-132. It is not stated in 800-63B-4 itself.

How to reconcile them

1. OWASP's general preference for Argon2id and NIST's FIPS-oriented requirements do not conflict. OWASP itself switches to PBKDF2 when FIPS is required.
2. Use PBKDF2-HMAC-SHA256 with at least 600,000 iterations. Raise the count as far as login latency allows, since NIST says the cost should be as high as practical.
3. Use a unique random salt of at least 32 bits per password, and store the salt, the hash and the parameters.
4. Add a secret key step (a pepper or keyed HMAC), stored separately and ideally in an HSM. Both OWASP and NIST support this. If your approved cryptographic module requires it, use a FIPS-validated implementation for the HMAC too.
5. Confirm that your cryptographic library or module is FIPS 140 validated and that your auditor accepts the exact PBKDF2 configuration. OWASP says validated implementations exist, but I did not verify any particular module.
6. Keep the parameters versioned so you can move to an NIST-approved successor later.

{"evidence": [
{"claim": "OWASP's general first choice is Argon2id with a minimum configuration of 19 MiB memory, 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": "OWASP says to use PBKDF2 with at least 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 states PBKDF2 is permitted by NIST SP 800-63B-4, has FIPS-140 validated implementations, and should be preferred when those are 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 lists 600,000 iterations as the recommended count for PBKDF2-HMAC-SHA256.", "quote": "PBKDF2-HMAC-SHA256: 600,000 iterations (recommended)", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP says a pepper should be stored separately from the password database, in a secrets vault or HSM.", "quote": "The pepper should be stored separately from the password database.", "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 says an approved scheme from the latest SP 800-132 (or updated NIST guidance) should be used, without naming an algorithm in 800-63B-4; the cost factor should be as high as practical.", "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 requires a salt of at least 32 bits, and requires both the salt and the hash to be 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 recommends an additional keyed hash or encryption iteration with a secret key stored separately, ideally in an HSM or TEE (analogous to a pepper).", "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"}
]}