Gated-execute on OWASP vs NIST on password hashing

Recommendation: use PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations, run inside a FIPS 140-validated crypto module. Add a unique salt for each password and a secret key ("pepper") kept in an HSM. That one design satisfies OWASP's FIPS-specific advice and the storage requirements in NIST SP 800-63B-4.

What OWASP recommends

The OWASP Password Storage Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) ranks the algorithms in this order:

• Argon2id first, at a minimum of 19 MiB memory, 2 iterations and parallelism 1.
• scrypt if Argon2id isn't available.
• bcrypt only for legacy systems, with a work factor of at least 10 and a 72-byte password limit.

It gives a separate rule for FIPS: "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 explains that PBKDF2 "is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations," so it should be the preferred choice when those are required. It also gives equivalent iteration counts for other hash functions:

• 220,000 for PBKDF2-HMAC-SHA512
• 1,400,000 for PBKDF2-HMAC-SHA1, which it calls "legacy only, do not select for new systems"

The cheat sheet dates these numbers to December 2022 testing on RTX 4000 GPUs. It also requires a unique salt for each password and says to consider a pepper, though it says a pepper alone adds no security.

What NIST SP 800-63B-4 requires

This is the current revision. It states that it "supersedes NIST Special Publication (SP) 800-63B" (https://pages.nist.gov/800-63-4/sp800-63b.html). It doesn't name an algorithm. Its rules are:

• Required (SHALL):

  • Passwords must be "salted and hashed using a suitable password hashing scheme."
  • The salt must be at least 32 bits.
  • The salt and the hash must both be stored.
  • If a secret key is used, it must come from an approved random bit generator and be stored separately from the hashes.

• Recommended (SHOULD):

  • Use an approved scheme from the latest revision of SP 800-132 or later NIST password-hashing guidance.
  • Set the cost factor as high as practical and raise it over time.
  • Store which scheme and cost factor each password used, so you can migrate later.
  • Add a keyed hash or encryption step with a secret key, ideally held in an HSM or a trusted execution environment.

The new revision doesn't give an iteration count. The previous revision did: it named "PBKDF2 [SP 800-132] and Balloon" as examples, said a memory-hard function SHOULD be used, and suggested "typically at least 10,000 iterations" (https://pages.nist.gov/800-63-3/sp800-63b.html). Revision 4 dropped all three points.

Where the two sources differ

• Preferred algorithm. OWASP's general choice, Argon2id, isn't the scheme NIST points to. NIST points to SP 800-132, which the previous revision identifies as the PBKDF2 standard. (I didn't open SP 800-132 itself.) NIST's wording here is a SHOULD rather than an absolute ban. In practice, FIPS 140 validation is what rules out other algorithms; that reasoning comes from OWASP, and NIST doesn't say it.
• Iteration count. OWASP's 600,000 is a concrete benchmark. NIST only says "as high as practical."
• Pepper. NIST recommends it (SHOULD). OWASP only says to "consider" it.

How to reconcile them

1. Use PBKDF2-HMAC-SHA-256 from a FIPS 140-validated module, at 600,000 iterations or more. Tune it upward over time; that covers both OWASP's minimum and NIST's "as high as practical."
2. Give every password a unique random salt of at least 32 bits (NIST's minimum). I'd suggest more; that's my own suggestion, not from either source.
3. Store the salt, the hash, and the scheme and cost parameters with each password.
4. Add an HMAC step keyed with a secret pepper. Generate the key with an approved random bit generator and keep it separately, ideally in an HSM.
5. Don't use PBKDF2-HMAC-SHA1 for new systems.
6. Don't pick Argon2id, scrypt or bcrypt for this service. OWASP's own FIPS rule points to PBKDF2 instead.

{"evidence": [
{"claim": "OWASP's general recommendation is Argon2id with minimum parameters 19 MiB, 2 iterations, 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 recommends scrypt 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 specifies 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 NIST 800-63B-4 or FIPS-140 compliance 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 calls PBKDF2-HMAC-SHA1 legacy only.", "quote": "PBKDF2-HMAC-SHA1: 1,400,000 iterations — legacy only, do not select for new systems.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP's PBKDF2 iteration figures date from December 2022 GPU testing.", "quote": "These configuration settings are equivalent in the defense they provide. (Number as of december 2022, based on testing of RTX 4000 GPUs)", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "SP 800-63B-4 is the current revision and 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": "NIST 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 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": "NIST 800-63B-4 sets no fixed iteration count; the cost 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 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": "NIST 800-63B-4 recommends storing the scheme and cost factor so passwords can be migrated.", "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 800-63B-4 recommends an extra keyed hash or encryption step with a verifier-only 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": "NIST 800-63B-4 requires the secret key to be stored separately from the hashes.", "quote": "The secret key value SHALL be stored separately from the hashed passwords.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "The previous revision (800-63B rev 3) named PBKDF2 (SP 800-132) and Balloon as examples, preferred memory-hard functions, and suggested at least 10,000 PBKDF2 iterations.", "quote": "Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON].", "url": "https://pages.nist.gov/800-63-3/sp800-63b.html"},
{"claim": "The previous revision's PBKDF2 iteration guidance was typically at least 10,000.", "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"}
]}