Password Hashing Best Practices: bcrypt, Argon2id, and scrypt

The fundamental problem with using general-purpose cryptographic hash functions (MD5, SHA-1, SHA-256) for passwords is that they are designed to be fast. SHA-256 can process approximately 3.5 billion hashes per second on a single modern GPU. When an attacker obtains a database of password hashes, they can test a dictionary of millions of common passwords against every hash in seconds. Combinations like adding numbers, capitalizing letters, or substituting characters are handled by rule-based cracking tools like Hashcat.

Password hashing algorithms — bcrypt, scrypt, and Argon2 — are deliberately slow and resource-intensive. They are designed with an adjustable cost factor (bcrypt), memory requirements (scrypt and Argon2), and parallelism limits (Argon2). This makes each individual hash comparison expensive in terms of CPU time and RAM, which means an attacker testing billions of guesses faces a prohibitive computational cost.

Salts prevent a separate class of attack: precomputation attacks. A rainbow table is a precomputed lookup table mapping hash values back to passwords. Without a salt, if two users choose the same password they produce the same hash, and an attacker can crack both simultaneously from a single table entry. A unique random salt per user means each password's hash is different even if the plaintext is identical. bcrypt, scrypt, and Argon2 all generate and store a unique salt automatically as part of the hash output string.

The OWASP Password Storage Cheat Sheet (published and regularly updated by the Open Web Application Security Project) provides the canonical guidance for password algorithm selection. As of 2024, OWASP's recommendation hierarchy is: Argon2id first, scrypt second (if Argon2id is unavailable), bcrypt third (for legacy compatibility), and PBKDF2 only when FIPS 140 compliance is required. MD5 and SHA-1 are explicitly prohibited. OWASP also notes that all new systems should use Argon2id unless there is a specific reason not to.

A common misconception is that adding pepper (a static secret known to the application but not stored in the database) to a password before hashing provides significant additional security. Pepper does help if the database is leaked but the application server is not compromised. However, it complicates key rotation (if the pepper changes, all passwords need rehashing) and provides false confidence. OWASP recommends pepper as an additional layer after choosing a strong algorithm, not as a substitute for a strong algorithm.

Start by searching your codebase for calls to fast cryptographic hash functions used on passwords. In Node.js: grep -r 'createHash\|md5\|sha1\|sha256' src/ and inspect which calls process user passwords. In Python: grep -r 'hashlib.md5\|hashlib.sha1\|hashlib.sha256' and verify if any are used for password storage. In PHP: grep -r 'md5(\|sha1(' and check the context. Any use of these functions on password values is a critical vulnerability.

For bcrypt hashes in your database, check the cost factor embedded in the hash string. A bcrypt hash looks like $2b$10$SALT22CHARS.HASHCHARS. The 10 between the second and third dollar signs is the cost factor (also called rounds). For 2026 hardware, OWASP recommends a minimum of 10 rounds with 12 as a good default for most applications. Cost factor 6–8 (set in older defaults) is now insufficient — a modern GPU can test approximately 100,000 bcrypt-10 hashes per second and over 1 million bcrypt-8 hashes per second.

For Argon2 hashes, the hash string encodes the parameters: $argon2id$v=19$m=19456,t=2,p=1$SALT$HASH. The m value is memory in KiB. If you find m values below 64000 (64 MB) in production hashes, consider upgrading. The OWASP minimum for Argon2id is m=19456 (19 MiB), with 64 MiB recommended if your hardware allows it.

Check for the same-salt anti-pattern: if all hashes in your database have the same salt prefix, or if you find code like bcrypt.hash(password + STATIC_SALT, rounds), you have a shared-salt vulnerability. The purpose of salting is that each password gets a unique salt. Look for any shared constant being concatenated with passwords before hashing.

To test bcrypt timing, run a benchmark on your production-equivalent hardware: time node -e "require('bcrypt').hashSync('test', 12)". OWASP recommends tuning the cost factor so that hash generation takes approximately 1 second on your production server. This balances security (high cost makes attacks expensive) with usability (1 second is acceptable for login) and DOS resistance (avoid factors so high that an attacker can exhaust server resources with many login attempts).

For Argon2id in Node.js, use the argon2 npm package (built on the reference implementation): const argon2 = require('argon2'). Call argon2.hash(password, { type: argon2.argon2id, memoryCost: 19456, timeCost: 2, parallelism: 1 }) for hashing and argon2.verify(hash, password) for verification. The library handles salt generation and embedding. For Python, use argon2-cffi: from argon2 import PasswordHasher; ph = PasswordHasher(memory_cost=19456, time_cost=2, parallelism=1); hash = ph.hash(password); ph.verify(hash, password).

For bcrypt in Node.js, the bcrypt package is most widely used: const bcrypt = require('bcrypt'). Call bcrypt.hash(password, 12) for hashing (second argument is cost factor / rounds). Call bcrypt.compare(password, hash) for verification — this returns a boolean and is timing-safe internally. Never use bcrypt.hashSync() in an async Node.js server — it blocks the event loop during the expensive computation, making every request wait. Always use the async versions.

For PBKDF2 in environments where FIPS 140 compliance is required (government systems, some financial institutions), use Node.js built-in crypto.pbkdf2() with SHA-512, at least 600,000 iterations (OWASP 2023 recommendation), and a 16-byte random salt: crypto.pbkdf2(password, salt, 600000, 64, 'sha512', callback). For Java, use javax.crypto.SecretKeyFactory with PBKDF2WithHmacSHA512 and the same iteration count.

For scrypt, the OWASP minimum parameters are N=65536, r=8, p=1 (approximately 64 MB of memory). Node.js has built-in scrypt support: crypto.scrypt(password, salt, 64, { N: 65536, r: 8, p: 1 }, callback). Note that scrypt does not embed the salt in its output like bcrypt and Argon2 do — you must store the salt separately alongside the hash.

Security warning: never implement these algorithms yourself. Always use a well-maintained library. Subtle implementation errors in memory management, constant-time comparison, or salt generation can completely undermine security. The libraries listed above (argon2, bcrypt) are maintained by security professionals, have been audited, and have years of production use behind them. Never use a custom hash function or an obscure library with few users and no security audit history.

bcrypt has a well-known 72-byte input truncation limit. The original bcrypt specification processes only the first 72 bytes of the password. A 73-character password and a 74-character password that differ only after character 72 will produce the same bcrypt hash, meaning both passwords will verify as correct. This is a collision vulnerability that affects bcrypt exclusively — Argon2id and scrypt do not have this limitation. Mitigate by pre-hashing the password with SHA-256 before passing it to bcrypt: bcrypt.hash(Buffer.from(sha256(password), 'hex'), rounds). The SHA-256 output is 64 bytes — within the 72-byte limit — and contains full entropy from the original password regardless of length.

Null bytes in passwords cause silent truncation in some implementations. The original crypt() function treated the password as a C string, stopping at the first null byte. Some bcrypt implementations inherited this behavior. A password containing a null byte may verify differently across implementations. Reject null bytes in passwords at the input validation layer, or hash the password's hex representation rather than the raw binary.

Pepper (a server-side secret added to passwords before hashing) is an additional layer that OWASP mentions as beneficial. The pepper is stored in application configuration, not in the database. If only the database is compromised, the attacker cannot crack passwords without the pepper. However, if both the database and application configuration are compromised, pepper provides no protection. Implementing pepper with key rotation support requires storing the pepper version identifier alongside each hash. This complexity is usually not worth the marginal security benefit over simply choosing a strong Argon2id configuration.

FIPS 140 compliance eliminates bcrypt and Argon2 as options because neither is approved by NIST's FIPS 140-2/3 standards. Environments requiring FIPS compliance must use PBKDF2 with an approved PRF (SHA-256 or SHA-512) and a compliant cryptographic module. Node.js OpenSSL can be configured in FIPS mode, which will throw errors if non-FIPS algorithms are used. Verify your FIPS requirements with your security compliance officer before committing to a password hashing algorithm.

Password migration from legacy hashing must not require forced password resets for all users simultaneously. The gradual rehashing on login approach (implemented in the examples section) is the standard solution. Maintain a hash_algorithm or hash_version column in the users table if your application supports multiple algorithms simultaneously during migration. Query this column at login to choose the correct verification method, then rehash with the current algorithm after successful verification.

Storing passwords in plaintext is the most extreme and unfortunately still occurring mistake. It requires no attack skill to exploit — a database dump immediately exposes all user credentials. If you find plaintext passwords in a database, treat it as an active security incident: assume all passwords are compromised, force password resets for all users, and check whether the same server stores other sensitive data.

Encrypting passwords (as opposed to hashing them) is a common misunderstanding. Encryption is reversible — anyone with the decryption key can recover the original password. Password storage must be one-way: the original password cannot be recovered from the stored value. If someone argues for password encryption to allow password recovery emails (showing users their existing password), the correct response is to explain that a password reset (not recovery) is the secure design. Password recovery is a user expectation, not a security requirement.

Not using constant-time comparison when verifying passwords opens a timing side-channel. A naive string comparison in many languages exits early as soon as a mismatch is found, leaking information about how many characters match. Use the comparison function provided by your hashing library (bcrypt.compare() and argon2.verify() are both timing-safe) or crypto.timingSafeEqual() in Node.js for custom comparisons.

Setting the bcrypt cost factor at application startup and never adjusting it is a long-term vulnerability. Hardware gets faster every year. A cost factor that required 0.5 seconds per hash in 2018 may require only 0.05 seconds per hash on 2026 hardware, making brute force 10x cheaper. Review and adjust cost factors annually. Add an endpoint to your admin interface that displays the current average hash time and warns when it drops below 500 ms.

Pre-hashing passwords with unsalted MD5 before bcrypt is a real pattern found in some PHP codebases (md5($password) passed to password_hash()). This is catastrophic: MD5 reduces 8+ character passwords to a 32-hex-character space with fewer unique values, and the MD5 hashes are recoverable from public rainbow tables. The bcrypt wrapper becomes useless because the input has been pre-weakened. Always pass the original plaintext password to bcrypt or Argon2.

Follow the OWASP Password Storage Cheat Sheet as your authoritative reference, reviewing it annually for updates. The current recommendation hierarchy is: Argon2id (primary choice), scrypt (when Argon2id is unavailable), bcrypt (for broad library compatibility), and PBKDF2 (for FIPS-required environments only). Document the algorithm and parameters used in your system design documentation and in code comments, so future maintainers understand the security rationale.

Tune cost factors for your specific hardware and traffic patterns. For Argon2id, start with the OWASP minimums (m=19456, t=2, p=1) and benchmark on production-equivalent hardware. If your servers can handle higher memory settings without exceeding 1-second hash time, increase m first (memory hardness is more effective against specialized hardware than time cost alone). For bcrypt, adjust rounds to achieve 200–500 ms per hash on your hardware — faster is acceptable for high-traffic login endpoints, slower is preferable for lower-traffic administrative accounts.

Implement account lockout to defend against online brute force, but design it carefully to avoid creating a denial-of-service vector. NIST SP 800-63B recommends allowing at least 100 failed attempts before lockout when using modern hashing algorithms, because the slow hash provides significant protection. Rate limiting by IP and by account, with exponential backoff and CAPTCHA challenges, provides a better trade-off than hard account lockout that can lock out legitimate users.

For high-security accounts (administrators, security personnel), consider requiring longer passwords or passphrases (16+ characters) rather than complexity rules. NIST SP 800-63B also recommends against mandatory periodic password changes (which lead to predictable increment patterns) in favor of changing passwords only upon evidence of compromise. This is a significant shift from older guidance and reflects modern understanding of how users actually handle forced resets.

Audit your password hashing regularly. Include a query like SELECT COUNT(*), SUBSTRING(password_hash, 1, 7) as algorithm FROM users GROUP BY algorithm in your quarterly security reviews to detect if any hashes use unexpected algorithms (indicating a configuration bug or migration error). Maintain a hash_version column to track migration progress. Set a target date for completing the migration of all legacy hashes and monitor progress against it.