Orchestrator-workers on OWASP vs NIST on password hashing

Short answer: If the service has to meet FIPS requirements, use PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations, run inside a FIPS 140-validated cryptographic module. If FIPS does not apply, OWASP's default is Argon2id. Three points could not be confirmed from the sources: whether Argon2, scrypt or bcrypt is FIPS-approved, the contents of SP 800-132, and the "Final" status of Rev. 4 on csrc.nist.gov.

What OWASP recommends

I took this from the OWASP Password Storage Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). It ranks the algorithms as follows:

1. Argon2id is the default, with a minimum of 19 MiB of memory, 2 iterations and parallelism 1. The page lists equal-strength variants that trade memory for iterations, such as 46 MiB with t=1 or 12 MiB with t=3.
2. scrypt is the fallback if Argon2id is unavailable, with N=2^17, r=8 and p=1 as the minimum.
3. bcrypt is for legacy systems only, with a work factor of at least 10 and a 72-byte password limit.
4. PBKDF2 is for when FIPS-140 compliance is required, with at least 600,000 iterations and HMAC-SHA-256 as the internal hash. For other hashes, the page gives 220,000 iterations for HMAC-SHA-512. It gives 1,400,000 for HMAC-SHA-1, marked "legacy only, do not select for new systems".

OWASP says PBKDF2 should be preferred when FIPS is required because it is "permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations".

OWASP also covers three supporting practices:

• Salts: Every password needs a unique salt.
• Peppers: A pepper is optional defense in depth. It is a shared secret stored separately from the database, and changing it forces password resets.
• Work factor: Tune it by experiment on your own servers. As a general rule a hash should take under one second. Raise the factor over time by re-hashing at the user's next login.

What the current NIST SP 800-63B requires

The current revision is SP 800-63B-4 (Rev. 4), at https://pages.nist.gov/800-63-4/sp800-63b.html. It says it supersedes the earlier SP 800-63B. The Rev. 3 page (https://pages.nist.gov/800-63-3/sp800-63b.html) carries a banner saying it was superseded by SP 800-63-4 as of August 1, 2025.

The csrc.nist.gov "final" page returned a 404, so I could not confirm a formal "Final" status from that site. The supersession wording is my basis for treating Rev. 4 as current.

Rev. 4 requires the following:

• Salted, hashed storage: Passwords SHALL be salted and hashed using a suitable password hashing scheme.
• Salt length: The salt SHALL be at least 32 bits.
• Cost factor: This is only a SHOULD. It is "as high as practical" and raised over time, with no number given.
• Algorithm: None is named. Rev. 4 says an approved scheme from SP 800-132 or updated NIST guidelines SHOULD be used.
• Keyed hash (pepper): Verifiers SHOULD add a keyed hash or encryption step using a secret key stored separately from the hashes.
• FIPS 140: Cryptography used by verifiers operated by or on behalf of federal agencies at AAL1 SHALL be validated to FIPS 140 Level 1. Rev. 4 ties FIPS 140 to modules validated under the CMVP. The workers reported the same wording at AAL2, and Level 1 or higher at AAL3.

Rev. 3 was more specific. It named PBKDF2 and Balloon as examples, said a memory-hard function SHOULD be used, and gave "typically at least 10,000 iterations". Rev. 4 dropped all three.

Where the sources disagree or leave gaps

• OWASP's NIST claim: OWASP says PBKDF2 is "permitted by NIST SP 800-63B-4". The Rev. 4 text the workers read does not name PBKDF2. It defers to SP 800-132 or later guidance. OWASP's claim is a reasonable reading, but it is not in Rev. 4's wording.
• Iteration counts: The 600,000 figure is OWASP's. NIST Rev. 4 gives no number, and the old Rev. 3 figure of 10,000 comes from a superseded revision. Treat OWASP's figure as the operative one.
• Unopened sources: I could not open SP 800-132 itself (several URLs returned 404). I also found no NIST or CMVP page saying whether Argon2, scrypt or bcrypt is FIPS-approved. OWASP's FIPS exception implies they are not, but no source says so directly.
• Scope: The FIPS 140 requirement in 800-63B-4 is stated for verifiers operated by or on behalf of federal agencies. Whether it binds this team depends on whether the service falls under that scope.

How the team should reconcile the two

1. Choose the algorithm: If FIPS governs the service, use PBKDF2-HMAC-SHA-256 with at least 600,000 iterations. This is the only choice both OWASP and NIST support. Use Argon2id only if the team's FIPS scope allows a non-validated algorithm, and check current SP 800-132 or successor guidance and the CMVP before relying on it.
2. Salt and store metadata: Use a random, unique salt. The NIST floor is 32 bits, and a longer salt is the safer practice. Store the scheme and cost factor with each hash so you can migrate later, as both sources encourage.
3. Run it in a validated module: Run the hashing in a FIPS 140-validated module. I did not verify any CMVP certificates myself.
4. Add a pepper: Add a secret keyed step, stored separately and ideally in an HSM. NIST makes this a SHOULD and OWASP calls it optional. It supplements the KDF and does not replace it.
5. Tune the work factor: Benchmark on your own hardware, keep hashing time reasonable, and raise the cost over time.

{"evidence": [
{"claim": "OWASP's default recommendation is Argon2id with a minimum of 19 MiB memory, 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 names scrypt as the fallback 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": "For legacy systems using bcrypt, use a work factor of 10 or more and with a password limit of 72 bytes.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "When FIPS-140 compliance is required, OWASP says to use PBKDF2 with 600,000+ iterations and HMAC-SHA-256.", "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 justifies PBKDF2 for FIPS by citing NIST SP 800-63B-4 and FIPS-140 validated implementations.", "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 marks PBKDF2-HMAC-SHA1 as 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 requires a unique salt per password.", "quote": "A unique salt must be added to each password to prevent attackers from using precomputed lookup tables like rainbow tables.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP says a pepper should be stored separately from the password database.", "quote": "The pepper should be stored separately from the password database.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP advises hashing time under one second as a general rule when tuning the work factor.", "quote": "As a general rule, calculating a hash should take less than one second.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP suggests upgrading work factors by re-hashing at next login.", "quote": "The most common approach to upgrading the work factor is to wait until the user next authenticates, then re-hash their password with the new work factor.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "SP 800-63B-4 (Rev. 4) 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": "The Rev. 3 page states it has been superseded by SP 800-63-4, so Rev. 4 is current.", "quote": "This revision of NIST SP 800-63 has been superseded by NIST SP 800-63-4 as of August 1, 2025.", "url": "https://pages.nist.gov/800-63-3/sp800-63b.html"},
{"claim": "Rev. 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": "Rev. 4 sets the cost factor as a SHOULD with no numeric value.", "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": "Rev. 4 names no algorithm and defers to SP 800-132 or updated NIST guidelines, as a SHOULD.", "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": "Rev. 4 sets a 32-bit minimum salt.", "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": "Rev. 4 recommends an additional keyed hashing or encryption step with a secret key (pepper-like).", "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": "Rev. 4 requires the secret key to be stored separately from the hashed passwords.", "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": "Rev. 4 ties FIPS 140 requirements to CMVP-validated cryptography.", "quote": "Throughout this document, [FIPS140] requirements are satisfied by security technologies, products, and services that utilize implementations of cryptography validated by the Cryptography Module Validation Program [CMVP].", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "Federal verifiers at AAL1 must use FIPS 140 Level 1 validated cryptography.", "quote": "Cryptography used by verifiers operated by or on behalf of federal agencies at AAL1 SHALL be validated to meet the requirements of [FIPS140] Level 1.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "The superseded Rev. 3 named PBKDF2 and Balloon as examples and recommended a memory-hard function; Rev. 4 dropped these.", "quote": "Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack.", "url": "https://pages.nist.gov/800-63-3/sp800-63b.html"},
{"claim": "Rev. 3 gave a PBKDF2 iteration guideline of at least 10,000, far lower than OWASP's 600,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"}
]}