Plan-execute on OWASP vs NIST on password hashing

I've gathered the sources and am now writing the answer. Short version: use PBKDF2-HMAC-SHA-256 from a FIPS 140-validated crypto module, with at least 600,000 iterations, plus a secret key held in an HSM. That meets OWASP's FIPS recommendation and the current NIST requirements. Argon2id, OWASP's first choice, belongs only in systems with no FIPS obligation.

1. What OWASP recommends

The OWASP Password Storage Cheat Sheet gives an order of preference (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html):

• Argon2id first, with at least 19 MiB of memory, 2 iterations and parallelism 1. The page lists other settings it treats as equally strong, such as 46 MiB with 1 iteration.
• scrypt if Argon2id isn't available: N=2^17, r=8, p=1.
• bcrypt only for legacy systems: work factor 10 or more, and passwords capped at 72 bytes.
• PBKDF2 when FIPS-140 compliance is required: 600,000 or more iterations with HMAC-SHA-256 (220,000 for HMAC-SHA-512). It calls PBKDF2-HMAC-SHA1 legacy only.

OWASP explains the FIPS choice by saying PBKDF2 "is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations." It also says to:

• consider a pepper, kept out of the database in a secrets vault or HSM, for extra defence;
• re-hash each password with the new settings the next time the user logs in;
• store the algorithm and work factor with each hash (for example, the PHC string format).

2. What the current NIST SP 800-63B requires

Which revision is current. Revision 4 is current. The Rev. 3 page says it "has been superseded by NIST SP 800-63-4 as of August 1, 2025" (https://pages.nist.gov/800-63-3/sp800-63b.html). The Rev. 4 page says it "supersedes NIST Special Publication (SP) 800-63B" and carries a timestamp of 26 Aug 2025 (https://pages.nist.gov/800-63-4/sp800-63b.html). I couldn't open the NIST CSRC catalogue page to get the formal status line (it returned 404), so this relies on those two pages.

Password storage rules in Rev. 4, section 3.1.1.2 (https://pages.nist.gov/800-63-4/sp800-63b.html):

• SHALL: passwords must be salted and hashed using a "suitable password hashing scheme."
• SHALL: the salt must be at least 32 bits and chosen to avoid collisions. The salt and the hash must both be stored.
• SHOULD: the cost factor should be as high as practical and should be raised over time.
• SHOULD: use an "approved password hashing scheme published in the latest revision of [SP800-132] or updated NIST guidelines." Note this is a SHOULD, not a SHALL.
• SHOULD: store a reference to the scheme and cost factor with each password, so it can be migrated later.
• Secret key (pepper): verifiers SHOULD add a keyed hashing or encryption step with a key only the verifier knows. If they do, the key SHALL come from an approved random bit generator and SHALL be stored apart from the hashes. It SHOULD be stored and used inside an HSM or a trusted execution environment.

What Rev. 4 doesn't say. It names no algorithm (no PBKDF2, no Balloon, no Argon2) and gives no iteration count. Its reference list cites SP 800-132 as "Recommendation for Password-Based Key Derivation." I couldn't open SP 800-132 itself (404 errors), so I can't quote its text.

FIPS rules elsewhere in Rev. 4. It defines "approved" as FIPS-approved or NIST-recommended. It also says cryptography used by verifiers run by or for federal agencies at AAL1 (and, unless otherwise specified, AAL2) SHALL be FIPS 140 Level 1 validated. Applying that to the password-hashing step is my reading, not explicit wording in the document.

What changed from Rev. 3 (https://pages.nist.gov/800-63-3/sp800-63b.html, superseded):

• Rev. 3 named PBKDF2 and Balloon as examples.
• It said a "memory-hard function SHOULD be used."
• It suggested "typically at least 10,000 iterations."
• It called the key a "secret salt" and required at least 112 bits of security strength.

None of that wording carries over to Rev. 4, so don't quote it as current.

3. Where the sources disagree, and how to reconcile them

Differences

• Algorithm: OWASP ranks Argon2id first. NIST Rev. 4 points only to "approved" schemes in SP 800-132, which the references list as a password-based key derivation document. OWASP's statement that PBKDF2 is "permitted by NIST SP 800-63B-4" is an inference; Rev. 4 never names PBKDF2.
• Work factor: OWASP gives a number (600,000 for PBKDF2-HMAC-SHA-256). Rev. 4 gives none; it says only "as high as practical." The old 10,000 figure is Rev. 3 and outdated.
• Pepper: OWASP says "consider" one. NIST makes it a SHOULD, with binding SHALL conditions if you use one.
• Salt: NIST sets a 32-bit minimum. OWASP gives no length and notes that libraries usually generate salts for you.

Recommendation for a FIPS-bound service

1. Algorithm: PBKDF2-HMAC-SHA-256 from a FIPS 140-validated module. This is OWASP's FIPS choice and fits NIST's pointer to SP 800-132.
2. Iterations: at least 600,000 (OWASP's minimum). Go higher if login performance allows, which satisfies NIST's "as high as practical."
3. Salt: random and unique per password, at least 32 bits (NIST's minimum). I'd suggest 128 bits, but that's my suggestion, not a source requirement.
4. Secret key: apply an HMAC with a secret key generated by an approved random bit generator, kept in an HSM and away from the database. This is OWASP's "post-hashing pepper" and NIST's extra keyed step.
5. Migration: store the algorithm and cost with each hash. When parameters change, re-hash on the user's next successful login.
6. Where Argon2id fits: only in components with no FIPS obligation. The sources I read don't show Argon2id as NIST-approved.

{"evidence": [
{"claim": "OWASP's first choice is Argon2id with at least 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's second choice is scrypt with N=2^17, r=8, p=1.", "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, with work factor 10 or more and a 72-byte limit.", "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": "OWASP says to use PBKDF2-HMAC-SHA-256 with 600,000 or more iterations 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 justifies PBKDF2 for FIPS contexts by NIST SP 800-63B-4 permission 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 treats a pepper as optional defence in depth.", "quote": "Consider using a pepper to provide additional defense in depth (though alone, it provides no additional secure characteristics).", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP says peppers belong in secrets vaults or HSMs.", "quote": "Peppers are secrets and should be stored in \"secrets vaults\" or HSMs (Hardware Security Modules).", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP recommends re-hashing with the new work factor at the user's 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": "Rev. 3 of SP 800-63 was superseded by SP 800-63-4 on August 1, 2025.", "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": "SP 800-63B-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": "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": "SP 800-63B-4 says the cost factor should be as high as practical.", "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": "SP 800-63B-4 points to approved schemes in SP 800-132 as a SHOULD and names no 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": "SP 800-63B-4 cites SP 800-132 as its recommendation on password-based key derivation.", "quote": "[SP800-132] Turan M, Barker E, Burr W, Chen L (2010) Recommendation for Password-Based Key Derivation.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "SP 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": "SP 800-63B-4 says the scheme and cost factor should be stored 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": "SP 800-63B-4 recommends an extra keyed hashing 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": "SP 800-63B-4 requires the secret key to be stored apart 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": "SP 800-63B-4 says the secret key should be stored and used in an HSM or TEE.", "quote": "It SHOULD be stored and used within a hardware-protected area, such as a hardware security module or trusted execution environment (TEE), such as a trusted platform module (TPM).", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "SP 800-63B-4 requires FIPS 140 validation of cryptography used by federal verifiers at AAL1.", "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": "SP 800-63B-4 defines approved cryptography as FIPS-approved or NIST-recommended.", "quote": "An encryption algorithm, hash function, random bit generator, or similar technique that is Federal Information Processing Standards (FIPS)-approved or NIST-recommended.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "The superseded Rev. 3 named PBKDF2 and Balloon as example functions.", "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 superseded Rev. 3 recommended a memory-hard function.", "quote": "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": "The superseded Rev. 3 suggested at least 10,000 PBKDF2 iterations.", "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"}
]}