The boring algorithm that just keeps working
bcrypt was designed in 1999. It is one of the few security algorithms from that era that is still an acceptable default in 2026.
That is impressive on its own. Most “secure” algorithms from twenty five years ago are now broken or deprecated. bcrypt is neither. It still appears at the top of most password storage recommendations, alongside the newer Argon2id.
The temptation is to assume the newest thing is automatically better. It is not always. bcrypt has properties that come from age: it is in every language, every framework supports it, every dev ops engineer has run into it before, and the failure modes are well understood. Boring is a feature.
How bcrypt works without going into the math
bcrypt takes your password and a “cost factor” you pick, runs the password through a slow function many times, and outputs a fixed length string that includes the cost factor inside.
The cost factor is exponential. Cost 10 is twice as slow as cost 9. Cost 12 is four times slower than cost 10. Higher cost equals slower hash equals more pain for an attacker who is trying billions of guesses.
The output looks like this: $2b$12$N9qo8uLOickgx2ZMRZoMye.... The 2b is the bcrypt version, the 12 is the cost factor, and the rest is the salt and hash. Everything you need to verify a password later is contained in that one string. You do not store the cost or the salt separately.
When the verifier checks a login, it parses the cost from the stored string, runs the same operation, compares the result. Same input, same cost, same answer.
The cost factor in 2026
In 2026, the right cost factor is between 12 and 14, depending on your hardware.
12 is the lower bound. Anything below 12 is too cheap for current attackers. 14 is fine if your servers can spare the CPU. The number you want is whatever takes between 250 and 500 ms per check on the production hardware. Faster than that, you are leaving margin on the table. Slower, your logins feel laggy.
The single most useful exercise: time bcrypt at cost 12, 13, and 14 on your real server, pick the highest one that stays under 500 ms. Repeat the test once a year as hardware gets faster.
bcrypt vs Argon2id: when each wins
Argon2id is the modern default and the OWASP first recommendation. It is memory hard (which makes graphics cards much less useful as attack hardware) and has formal analysis behind it.
bcrypt is older, less memory hard, but more battle tested. Every language has a working library, and you do not have to think about memory parameters because there are none.
The honest comparison:
- New code in 2026: Argon2id is probably the right pick.
- Existing code with bcrypt: stay on bcrypt, it is still defensible. Migrate only when you are doing a larger overhaul.
- Memory constrained environments: bcrypt, because Argon2 wants 32 to 64 MB per hash and bcrypt is fine with kilobytes.
The wrong choice is to migrate just because Argon2 is newer. Migration of password hashes is the kind of change that goes wrong in subtle ways, and bcrypt at cost 13 is not the weak link in your security model.
What still trips people up
A few common mistakes:
Truncating the password. bcrypt has a 72 byte limit on input. If your users have very long passphrases, anything past byte 72 is silently ignored. Modern libraries warn or refuse, older ones silently truncate. Verify your library’s behaviour.
Reusing the same salt. Some homemade integrations strip out the salt thinking it is wasted bytes. Without a per password salt, two users with the same password get the same hash, and the entire database becomes attackable as one batch. Never modify the bcrypt output, store it as is.
Forgetting to upgrade cost. The cost you set in 2018 is too cheap in 2026. The right pattern: on every successful login, check if the cost is below your current target. If yes, rehash and update. Over time, every active account moves to the new cost.
Comparing with ==. Use the bcrypt library’s verify function, not string equality. The verify function uses a constant time comparison that does not leak information through timing attacks.
A practical 2026 checklist
If you have bcrypt today: keep it. Bump the cost to 12 or 13, add the auto upgrade on login.
If you are starting fresh: pick Argon2id with the parameters from the hash passwords post, unless you have a specific reason to prefer bcrypt.
If you have something worse (SHA-256, MD5, plain hash): migrate. The wrap-old-hash pattern is the right approach, both bcrypt and Argon2 work fine wrapping a legacy hash.
When you need to inspect a stored hash format (parse out the cost, the version, the salt), the hash generator on AldeaCode runs in your browser and shows you what each piece is. The base64 encoder helps when the hash is encoded for transport.
bcrypt is not exciting. It is twenty five years old, the math has not changed, and it does the same boring work it always did. That is exactly why it still belongs in the conversation.