Orchestrator-workers on OWASP vs NIST on password hashing

Password Hashing Under OWASP and NIST SP 800-63B-4: Choosing an Algorithm for a FIPS-Constrained Service

Short answer

Use PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations, with a random salt for each password, and run it inside a FIPS 140-validated cryptographic module. This is what OWASP recommends when FIPS-140 compliance is required. It also meets the binding (SHALL) storage requirements of NIST SP 800-63B-4 and follows its recommendation (SHOULD) to use a scheme approved in SP 800-132. OWASP's general first choice is Argon2id, but nothing the research could verify shows Argon2id as approved by NIST or FIPS.

What OWASP recommends

The OWASP Password Storage Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) ranks the options as follows:

1. Argon2id first. The minimum is 19 MiB of memory, 2 iterations and parallelism of 1. The page lists several other memory/iteration combinations that it says protect equally well.
2. scrypt if Argon2id isn't available. Minimums are N=2^17, r=8, p=1.
3. bcrypt only in legacy systems where neither Argon2 nor scrypt is available. The work factor must be at least 10.
4. PBKDF2 when FIPS-140 compliance is required. The internal hash should be HMAC-SHA-256 with 600,000 or more iterations. Alternatively, HMAC-SHA512 can be used with 220,000 iterations.

OWASP justifies the PBKDF2 choice by saying it "is permitted by NIST SP 800-63B-4 and has FIPS-140 validated implementations." It treats PBKDF2-HMAC-SHA1 (1,400,000 iterations) as legacy only. It cites NIST SP 800-131A Rev. 2 for SHA-1's phase-out, but that is OWASP describing NIST. No worker checked SP 800-131A itself.

OWASP also says:

• Salt: every password gets its own unique random salt.
• Pepper: optional defence in depth, stored separately from the password database.
• bcrypt's 72-byte limit: this cap must be enforced. Pre-hashing before bcrypt is risky because of null bytes and "password shucking." OWASP's safe pattern is bcrypt(base64(hmac-sha384(password, pepper))).
• Legacy hashes: rehash when the user next logs in, or wrap old hashes in a stronger algorithm. Store the algorithm and parameters in a standard format such as PHC.

The page is not fully consistent. It announces "three" algorithms but covers four, and its introduction leaves out scrypt.

What NIST SP 800-63B-4 requires

Current revision. Revision 4 is current. The Rev 3 page states it was superseded by SP 800-63-4 as of August 1, 2025 (https://pages.nist.gov/800-63-3/sp800-63b.html). The Rev 4 page itself showed no formal publication date.

Requirements (SHALL). Section 3.1.1.2 of Rev 4 (https://pages.nist.gov/800-63-4/sp800-63b.html) requires that:

• passwords be "salted and hashed using a suitable password hashing scheme";
• the salt be at least 32 bits long;
• the salt and the hash both be stored for each password.

Recommendations (SHOULD). The same section recommends that:

• the scheme be "An approved password hashing scheme published in the latest revision of [SP800-132] or updated NIST guidelines on password hashing schemes";
• the cost factor be as high as practical and raised over time;
• a reference to the scheme and cost factor be stored with each password;
• verifiers add a keyed hashing or encryption step with a secret key (a pepper). If a pepper is used, it SHALL be generated by an approved random bit generator and stored separately from the hashes. It SHOULD be kept in an HSM or TEE.

What Rev 4 does not say. It names no specific algorithm and gives no iteration count. The worker found no mention of "PBKDF2" anywhere on the page.

FIPS 140 for federal verifiers. Cryptography used by federal verifiers at AAL1 SHALL be validated to FIPS 140 Level 1. That requirement is met by cryptography validated by the CMVP.

Other password rules in Rev 4:

• at least 15 characters when the password is the only factor, and at least 8 when it is part of multi-factor authentication;
• no composition rules;
• a mandatory blocklist check when a password is set or changed.

Differences from Rev 3. Rev 3 named "PBKDF2 [SP 800-132] and Balloon" as example functions, said "A memory-hard function SHOULD be used," and suggested "typically at least 10,000 iterations." Rev 4 dropped all three. The 10,000 figure is outdated and far below OWASP's 600,000.

How the two fit together

The two sources do not conflict on the FIPS path. They work at different levels:

• NIST sets outcome requirements (salted, suitable scheme, salt of at least 32 bits, pepper recommended) and points to SP 800-132 for approved schemes.
• OWASP names a concrete algorithm and concrete parameters.

PBKDF2 is the link. Rev 3 explicitly ties PBKDF2 to SP 800-132, and OWASP picks PBKDF2 for FIPS contexts. So PBKDF2-HMAC-SHA-256 with at least 600,000 iterations satisfies OWASP's FIPS branch, NIST's SHALLs and NIST's SP 800-132 SHOULD. The 600,000 figure comes from OWASP; NIST Rev 4 sets no number, only "as high as practical."

What the team should build:

• PBKDF2-HMAC-SHA-256 at 600,000 iterations or more, with a per-password random salt of at least 32 bits.
• A pepper kept in an HSM or TEE, which both sources recommend.
• The scheme and cost stored with each hash, for example in PHC format, which both sources recommend.
• Rehashing at login to raise the cost factor or migrate algorithms later.
• The hashing run inside a CMVP-validated module. Approval of the algorithm on paper is not enough. This last point is my inference from NIST's FIPS 140 wording.

Where the two sources diverge, and what remains unverified

Argon2id. OWASP prefers Argon2id in general, but no NIST page the workers opened names Argon2, scrypt or bcrypt. RFC 9106 (https://www.rfc-editor.org/rfc/rfc9106.html) is an Informational document, not standards-track, and specifies Argon2 with BLAKE2b. The claim that these algorithms are not FIPS-approved therefore rests on OWASP and on NIST's silence. It is not confirmed by a primary NIST or CMVP list, because those pages, along with SP 800-132 and SP 800-140C, returned 404 to the workers.

SP 800-132 details. Its specific requirements on salt, iteration count and the underlying function were not retrieved.

OWASP's wording. OWASP's claim that PBKDF2 is "permitted" by SP 800-63B-4 fits Rev 4's pointer to SP 800-132. However, Rev 4 itself never names PBKDF2.

Future NIST guidance. Whether NIST plans new password-hashing guidance, such as memory-hard functions, could not be confirmed.

{"evidence": [
{"claim": "OWASP's default recommendation 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 restricts 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": "OWASP recommends PBKDF2-HMAC-SHA-256 with 600,000+ 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 by reference to 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 treats PBKDF2-HMAC-SHA1 as legacy only, citing SP 800-131A Rev. 2 (unverified against NIST).", "quote": "PBKDF2-HMAC-SHA1: 1,400,000 iterations — legacy only, do not select for new systems. NIST SP 800-131A Rev. 2 disallows SHA-1 for new use after 2030.", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP limits bcrypt input to 72 bytes.", "quote": "bcrypt has a maximum length input length of 72 bytes for most implementations, so you should enforce a maximum password length of 72 bytes (or less if the bcrypt implementation in use has smaller limits).", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html"},
{"claim": "OWASP says the pepper must 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 recommends storing algorithm and work factor in a standard format such as PHC.", "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": "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 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 recommends (SHOULD) a scheme approved in SP 800-132 or later NIST guidance, 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 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 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 recommends storing the scheme and cost factor 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 additional keyed hashing 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": "SP 800-63B-4 recommends keeping the secret key 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": "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": "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": "SP 800-63B-4 requires 15-character minimum for single-factor passwords.", "quote": "Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "SP 800-63B-4 forbids composition rules.", "quote": "Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "SP 800-63B-4 requires a blocklist check.", "quote": "When processing a request to establish or change a password, verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords.", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"},
{"claim": "Rev 3 named PBKDF2 (tied to SP 800-132) and Balloon as example KDFs.", "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": "Rev 3 recommended a memory-hard function, which Rev 4 dropped.", "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": "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"},
{"claim": "Argon2's RFC is Informational, not standards-track.", "quote": "This document is not an Internet Standards Track specification; it is published for informational purposes.", "url": "https://www.rfc-editor.org/rfc/rfc9106.html"},
{"claim": "Argon2 as specified in RFC 9106 uses BLAKE2b.", "quote": "Even though Argon2 can be potentially used with an arbitrary function H, as long as it provides outputs up to 64 bytes, the BLAKE2b function [BLAKE2] is used in this document.", "url": "https://www.rfc-editor.org/rfc/rfc9106.html"}
]}