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.
Related Articles
bcrypt vs Argon2: Password Hashing
bcrypt has protected passwords for decades; Argon2 is the modern, memory-hard recommendation. Here is how they compare and when to use each in 2026.
How to Decrypt AES-256-GCM Locally
Decrypting AES-256-GCM is straightforward when you have the password and the right metadata. Here is the exact workflow—and the mistakes that break decryption.
QR Code Printing: Size, Contrast, Materials
A QR code that fails to scan on paper is a broken link. Get the minimum size, contrast, error correction, and quiet-zone rules right before sending the file to print.
Developer Security Tools: Zero-Knowledge Guide
The tools you reach for with sensitive data should not see that data. A guide to the zero-knowledge security toolbox: what each tool does, when to use it, and how to verify it.
Encrypt .env Files Before Commit
Committing a plaintext .env leaks every secret in your repository. If a copy must live in git, encrypt it first - here is the safe workflow.
Verify Downloaded ISO Checksums: Linux, Windows, and macOS
A corrupted ISO can fail hours into an install. Verify the SHA-256 checksum before you burn or write it, and never upload the file to do it.