Pair your password hashing with strong random passwords from the Password Generator.
Why you cannot hash passwords with SHA
SHA-256 and friends are designed to be fast, and attackers love fast: dedicated hardware can test billions of guesses per second against a leaked hash database.
Password hashing must therefore be deliberately expensive. bcrypt and scrypt both add a per-user salt and a tunable work factor so each guess costs real time, memory, or both.
How bcrypt works
bcrypt is built on the Blowfish cipher key schedule. A cost factor (2^cost iterations) controls how expensive each hash is, and a 128-bit salt is stored with the result.
Its main limitation is a 72-byte input cap: longer passwords are truncated unless the library pre-hashes them. And because it is CPU-bound, GPU clusters can still crack low-cost bcrypt hashes quickly.
How scrypt differs
scrypt is memory-hard: it fills a large block of memory while deriving the key, so an attacker must either spend large amounts of RAM per guess or fall back to slow recomputation.
Parameters N (CPU/memory cost), r (block size), and p (parallelization) tune the trade-off. Memory hardness gives scrypt better resistance to GPU and ASIC cracking than bcrypt at comparable settings.
bcrypt vs scrypt at a glance
| Property | bcrypt | scrypt |
|---|---|---|
| Type | CPU-bound | Memory-hard |
| Input limit | 72 bytes | Effectively unlimited |
| Key parameters | cost (2^cost iterations) | N, r, p |
| GPU/ASIC resistance | Moderate | Stronger |
| Ecosystem | Very widely available | Widely available, fewer defaults |
What to use in 2026
- First choice: Argon2id, the modern memory-hard winner with dedicated hardware resistance
- Second choice: scrypt when Argon2 is unavailable
- Legacy: bcrypt is still acceptable if you use cost ≥ 12 and pre-hash inputs longer than 72 bytes
- Always use a per-user random salt and never roll your own algorithm
Warning: Do not add pepper-style secrets, double hashing, or custom iterations "for extra security" without reason. Complexity invites implementation bugs; standard algorithms with sane parameters win.
FAQ
Q.Is bcrypt still safe in 2026?
A.Yes, with a sufficient cost factor (≥ 12) and a per-user salt. It remains a reasonable choice, but Argon2id and scrypt offer better resistance to GPU and ASIC attacks for new systems.
Q.What cost factor should I use?
A.The highest value your users tolerate. Measure login latency: target roughly 100–300 ms on your hardware, then add headroom for future CPU upgrades.
Q.Can I use scrypt in Node.js?
A.Yes. Node.js ships crypto.scrypt and crypto.scryptSync natively, and most frameworks provide scrypt or Argon2 bindings. Use the async variant to avoid blocking the event loop.
References
- OWASP Password Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- NIST SP 800-63B – Digital Identity Guidelines: Authentication: https://pages.nist.gov/800-63-3/sp800-63b.html
Start with a strong password
Random passwords with custom rules, generated in your browser.
Order of preference
Pick Argon2id when your framework ships it, scrypt when it does not, and keep bcrypt with cost at least 12 for legacy compatibility. Salt every password with fresh random bytes.
Start with strong input: generate random passwords locally with the Password Generator.