Create strong passwords worth hashing with our Password Generator — fully local, no account.
Why password hashing must be slow
Ordinary hashes like SHA-256 or MD5 are designed to be fast. For passwords that is a problem: an attacker can try billions of guesses per second on a GPU.
Password hashing algorithms deliberately add cost—CPU work, memory, or both—so each guess is expensive. The right choice balances that cost against your server's resources and user experience.
How bcrypt works
bcrypt (1999) is based on the Blowfish cipher. It takes a password, a 16-byte salt, and a cost factor: the work doubles with every increment, so cost 12 means 2^12 rounds.
bcrypt is CPU-bound but not memory-hard, which means dedicated GPU/ASIC rigs can still crack many bcrypt hashes in parallel. It also truncates passwords longer than 72 bytes.
You can try bcrypt-style generation locally with our Password Generator to see how salt and random output combine before hashing.
How Argon2 works
Argon2 (RFC 9106, 2015) is the winner of the Password Hashing Competition. Argon2id, the hybrid variant, is what OWASP and most security guidance recommend.
It is memory-hard: the algorithm fills a large block of memory (parameter m) and iterates over it (parameter t), making parallel GPU cracking and custom hardware much less effective.
Argon2 has no practical password length limit and lets you tune memory, iterations, and parallelism independently.
bcrypt vs Argon2 at a glance
- Algorithm – bcrypt (Blowfish-based, 1999) vs Argon2 (RFC 9106, 2015; Argon2id recommended)
- Memory-hard – bcrypt: no; Argon2: yes, defeats GPU/ASIC parallelism
- Password limit – bcrypt: 72 bytes; Argon2: no practical limit
- Tuning – bcrypt: cost factor only; Argon2: memory (m), iterations (t), parallelism (p)
- Ecosystem – bcrypt: ubiquitous in Node, Python, PHP, Go; Argon2: native or well-supported in most modern libraries
Which one should you choose?
If you already use bcrypt, it is still acceptable in 2026—raise the cost factor to at least 10-12 and plan a gradual migration to Argon2id. If FIPS constraints apply, PBKDF2 (OWASP recommends 600,000+ iterations for SHA-256) may be required, though it is weaker against dedicated hardware. For comparison, the AES tools on this site derive keys with PBKDF2-HMAC-SHA256 at 100,000 iterations and a fresh 16-byte salt: enough for a browser, below what OWASP advises for long-lived secrets.
If you already use bcrypt, it is still acceptable in 2026—raise the cost factor to at least 10-12 and plan a gradual migration to Argon2id. If FIPS constraints apply, PBKDF2 (OWASP recommends 600,000+ iterations for SHA-256) may be required, though it is weaker against dedicated hardware.
Whatever you choose, never store plaintext passwords, never use unsalted fast hashes, and verify the final hash locally before shipping.
Frequently Asked Questions
Q.Why Argon2id and not Argon2i or Argon2d?
A.Argon2id is the hybrid recommended by RFC 9106 and OWASP: it resists side-channel attacks on the first part of the pass (like Argon2d) while keeping tradeoff resistance (like Argon2i). Unless you have a specific threat model, use Argon2id.
Q.Is bcrypt still acceptable in 2026?
A.Yes, with a cost factor of at least 10-12 and 16-byte salts. It is not memory-hard, so it is weaker against GPU farms than Argon2id, but it remains a solid choice where libraries or FIPS constraints make Argon2 impractical.
Q.What parameters should I use for Argon2id?
A.Start with m=19 MiB (or 64 MiB if your servers allow), t=2-3 iterations, and p=1 parallelism with a 16-byte random salt. Measure on real hardware and keep verification under roughly 0.5-1 second.
Q.How do ZeyroVault tools relate to password hashing?
A.Our password generator creates long random passwords suitable for hashing with bcrypt or Argon2, and every operation runs in your browser—you can test your hashing strategy locally without sending data anywhere.
References
- RFC 9106 – Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications: https://www.rfc-editor.org/rfc/rfc9106
- OWASP Password Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- NIST SP 800-63B – Digital Identity Guidelines: Authentication and Lifecycle Management: https://pages.nist.gov/800-63-3/sp800-63b.html
- Provos & Mazières, A Future-Adaptable Password Scheme (USENIX 1999): https://www.usenix.org/conference/1999-usenix-annual-technical-conference/future-adaptable-password-scheme
Generate strong passwords locally
Create long, random, unique passwords in your browser — no upload, no account.
Conclusion
Argon2id is the default for new password hashing in 2026, with bcrypt still a defensible legacy choice at cost 10-12. Use a memory-hard, salted, slow algorithm—and never a fast generic hash.
Related Articles
bcrypt vs scrypt: Hashing Compared
Plain SHA hashes are too fast for passwords. bcrypt raises the CPU cost per guess; scrypt adds a memory bill that GPU rigs cannot easily pay. The practical ranking today is Argon2id, scrypt, then bcrypt.
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.