Plan-execute on OWASP vs NIST on password hashing

Short answer: To meet FIPS, use PBKDF2 with HMAC-SHA-256 at OWASP's stated work factor and a unique salt. If FIPS isn't a constraint, use Argon2id. NIST SP 800-63B-4 names no specific algorithm, so OWASP's FIPS fallback and NIST's requirements don't conflict.

What OWASP recommends

The cheat sheet's summary lists these options in order:

• Argon2id is the first choice. OWASP says to use "Argon2id with a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism."
• If Argon2id isn't available, use scrypt (minimum CPU/memory cost 2^17, block size 8, parallelization 1).
• bcrypt is for legacy systems only, with a work factor of 10 or more and a 72-byte password limit.
• For FIPS, it says "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."

The PBKDF2 section adds that it "is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations, it should be the preferred algorithm when these are required."

Its iteration counts are:

• PBKDF2-HMAC-SHA256: 600,000, which it marks as recommended.
• PBKDF2-HMAC-SHA512: 220,000.
• PBKDF2-HMAC-SHA1: 1,400,000, which it marks as legacy only.

OWASP also recommends salting and, optionally, a pepper. It says calculating a hash "should take less than one second." These numbers are from the page as I read it today (2026-10-13), and OWASP says work factors should be raised over time.

What NIST SP 800-63B requires

The current revision is SP 800-63B-4. The page I opened is dated 26 Aug 2025 and says "This publication supersedes NIST Special Publication (SP) 800-63B." That is the Rev 3 document. The requirements for password storage are:

• Verifiers must store passwords in a form resistant to offline attacks. Passwords "SHALL be salted and hashed using a suitable password hashing scheme."
• The salt "SHALL be at least 32 bits in length" and must be chosen to minimize collisions among stored hashes. The salt and the hash must both be stored.
• The cost factor "SHOULD be as high as practical without negatively impacting verifier performance" and should increase over time.
• "An approved password hashing scheme published in the latest revision of [SP800-132] or updated NIST guidelines on password hashing schemes SHOULD be used." This is a SHOULD, not a SHALL.
• Storing the scheme and cost factor with each password is a SHOULD, so you can migrate later.
• Verifiers SHOULD also do an extra keyed hash or encryption step with a secret key held only by the verifier. That key should be stored separately and ideally in an HSM or TEE.

The text I read does not name Argon2, scrypt or bcrypt. It names no minimum iteration count and does not mention FIPS 140. It points to SP 800-132 (a 2010 publication on password-based key derivation) as the source of approved schemes. I could not open SP 800-132 itself: the csrc.nist.gov URL I tried returned a 404. So I am relying on the 800-63B-4 and OWASP pages for what it covers, and I cannot say from a source whether Argon2, scrypt or bcrypt is on any NIST or CMVP approved list.

How Rev 4 differs from Rev 3

Rev 3 (https://pages.nist.gov/800-63-3/sp800-63b.html) was more specific. It listed PBKDF2 and Balloon as examples of suitable key derivation functions. It also said "the iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations." Rev 4's text has no 10,000 figure. Both revisions require a salt of at least 32 bits.

How to reconcile them

• The two sources don't conflict. OWASP's first choice is Argon2id. NIST's text does not mention Argon2id, and it points to SP 800-132 for approved schemes. OWASP itself handles the gap with its FIPS-140 fallback.
• If the service must satisfy FIPS, use PBKDF2-HMAC-SHA-256 at OWASP's 600,000 iterations or more. Use a unique random salt of at least 32 bits (longer is fine). Store the scheme and cost with each hash, and add a pepper kept in an HSM or a secrets vault.
• If FIPS is not binding, use Argon2id.
• Running PBKDF2 inside a FIPS-validated cryptographic module is my inference. OWASP says only that FIPS-140 validated implementations exist, and I didn't find a NIST statement on it. Confirm the module's validation status and whether your assessor requires it.
• Treat 600,000 as a floor and benchmark it on your own hardware. The 10,000 in Rev 3 is outdated and far below OWASP's figure. Use OWASP's figure, since NIST 800-63B-4 sets no number.

{"evidence": [
{"claim": "OWASP's first-choice recommendation is Argon2id with a stated minimum configuration.", "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 FIPS-140 fallback is 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 ties PBKDF2 to NIST SP 800-63B-4 and to 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 limits bcrypt to legacy use.", "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": "SP 800-63B-4 supersedes the earlier SP 800-63B (Rev 3).", "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 only says an approved scheme from SP 800-132 SHOULD be used, and does not name specific algorithms.", "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 a minimum salt length of 32 bits and requires storing salt and hash.", "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 800-63B-4 asks for a cost factor as high as practical, increased over time, without giving a 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": "Rev 3 named PBKDF2 and Balloon as examples and suggested at least 10,000 iterations, which Rev 4 does not state.", "quote": "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"}
]}