Propose-select on OWASP vs NIST on password hashing

Use PBKDF2 with HMAC-SHA-256, a unique random salt per password, and at least 600,000 iterations, run inside a FIPS 140-validated crypto module. Add a keyed "pepper" step whose key is kept away from the password database, ideally in a hardware security module (HSM). This is what OWASP recommends when FIPS 140 compliance is required, and it meets the current NIST SP 800-63B (Revision 4, which replaces earlier versions). The two sources mostly agree, with two caveats below.

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

• Default ranking: Argon2id first, with at least 19 MiB memory, 2 iterations and parallelism 1. Use scrypt if Argon2id isn't available. Use bcrypt only in legacy systems.
• FIPS case: "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." OWASP's reason is that PBKDF2 "is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations."
• SHA-1: PBKDF2-HMAC-SHA1 is "legacy only, do not select for new systems."
• Pepper: OWASP says to consider one as defense in depth.
• Upgrades: store the algorithm and work factor with each hash, for example in PHC string format, so you can move to stronger settings later.
• Long passwords: some PBKDF2 implementations are open to denial of service when users submit very long passwords.

What NIST SP 800-63B-4 requires (https://pages.nist.gov/800-63-4/sp800-63b.html)
The page says it supersedes the earlier SP 800-63B. The Rev. 3 page also says it was superseded as of August 1, 2025 (https://pages.nist.gov/800-63-3/sp800-63b.html).

• Required (SHALL):

  • Passwords must be "salted and hashed using a suitable password hashing scheme."
  • The salt must be at least 32 bits.

• Recommended (SHOULD):

  • Use "an approved password hashing scheme published in the latest revision of [SP800-132]." The reference list identifies SP 800-132 as the "Recommendation for Password-Based Key Derivation."
  • Set the cost factor "as high as practical."
  • Store a reference to the scheme and cost factor with each password so you can migrate later.
  • Add a keyed hashing or encryption step using a secret key known only to the verifier.
• FIPS 140: cryptography used by verifiers run by or for federal agencies at AAL1 (the lowest authentication assurance level) "SHALL be validated to meet the requirements of [FIPS140] Level 1." The document says this is met by implementations validated under NIST's Cryptographic Module Validation Program (CMVP). I only quoted the AAL1 sentence, so check the wording for your own assurance level.

Where the sources don't line up

1. NIST names no algorithm. The password-storage section of Rev. 4 never mentions PBKDF2. It only points to SP 800-132 and sets no iteration count. So OWASP's statement that PBKDF2 "is permitted by NIST SP 800-63B-4" is OWASP's interpretation, not NIST's wording.

   • Rev. 3, now superseded, did name "PBKDF2 [SP 800-132] and Balloon" as examples.
   • Rev. 3 said a memory-hard function SHOULD be used and suggested "typically at least 10,000 iterations."
   • I found neither of those in the Rev. 4 section. Anyone quoting 10,000 iterations or the memory-hard advice is citing outdated text.
   • I couldn't open SP 800-132 itself, so I haven't confirmed exactly what it approves.
2. OWASP's first choice may not pass a federal audit. Federal verifiers must use FIPS-validated cryptography. Neither NIST document I read mentions Argon2id, scrypt or bcrypt, and OWASP's own FIPS case points to PBKDF2. My conclusion (neither source says this directly) is that Argon2id shouldn't be used where FIPS applies.
3. Iteration count: 600,000 is OWASP's number. NIST only says "as high as practical," and 600,000 fits within that.
4. Pepper: NIST's wording (SHOULD) is stronger than OWASP's ("consider"). Follow NIST.

What the team should do

1. Confirm the FIPS scope: is the service run by or for a federal agency, and at which assurance level?
2. Choose a crypto module that is actually FIPS 140-validated, and make sure its PBKDF2 is available in the module's approved mode.

3. Set up PBKDF2-HMAC-SHA256:

   • at least 600,000 iterations;
   • a unique random salt of at least 32 bits per password (128 bits is a common choice, which is my suggestion, not either source's);
   • the algorithm and cost factor stored with each hash.
4. Add an HMAC pepper. Generate its key with an approved random bit generator and keep it away from the database, ideally in an HSM.
5. To guard against the long-password denial-of-service issue, use a library that pre-hashes long input once, or set a sensible maximum password length.
6. Measure login delay on your own servers and raise the iteration count over time. Rehash each user's password at their next login.
7. Before an audit, get SP 800-132 and confirm the approved scheme and parameters.

{"evidence": [
{"claim": "OWASP's default first choice is Argon2id with stated minimum parameters.", "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 scrypt if Argon2id isn't available.", "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": "When FIPS-140 compliance is required, OWASP recommends PBKDF2-HMAC-SHA-256 with 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 is permitted by SP 800-63B-4 and has 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 says PBKDF2-HMAC-SHA1 is 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 suggests a pepper as defense 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 advises storing the algorithm and work factor with each hash.", "quote": "Using a mix of hashing algorithms is easier if the password hashing algorithm and work factor are stored with the password using a standard format, for example, the modular PHC string format.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP warns of denial of service from very long passwords.", "quote": "When users supply very long passwords, a potential denial of service vulnerability could occur, such as the one published in Django during 2013.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.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": "Rev. 3 was superseded by SP 800-63-4 as of 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 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": "SP 800-63B-4 recommends (SHOULD) an approved scheme from the latest SP 800-132, without naming an 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 identifies SP 800-132 as the password-based key derivation recommendation.", "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 asks for a cost factor as high as practical, with no fixed number.", "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 sets a minimum salt length of 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 recommends storing a reference to the scheme and cost factor for 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 hash with 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 requires federal verifiers' cryptography at AAL1 to be FIPS 140 Level 1 validated.", "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 says FIPS 140 requirements are met by 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": "The superseded Rev. 3 named PBKDF2 and Balloon and recommended a memory-hard function.", "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 suggested at least 10,000 PBKDF2 iterations, far below 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"}
]}