What Is Bcrypt and Why Is It Still the Go-To for Passwords?

Every few years, someone writes a hot take declaring bcrypt dead. "Use Argon2," they say. "Use scrypt." And honestly? Those are fine algorithms. But bcrypt keeps showing up in production codebases at some of the most security-conscious companies in the world, and in 2026 it still holds up remarkably well. Let's dig into why — question by question.

So what exactly is bcrypt?

Bcrypt is a password hashing function designed in 1999 by Niels Provos and David Mazières. It was built specifically for one job: storing passwords in a way that makes an attacker's life miserable even if they steal your database.

It's based on the Blowfish cipher, but that's kind of a red herring. The cipher is used as a building block inside a key-setup algorithm called Eksblowfish — "expensive key schedule Blowfish." The expensive part is the point. Bcrypt was never trying to be fast. It was trying to be deliberately, tuneably slow.

What's this "cost factor" everyone mentions?

This is the part that makes bcrypt genuinely clever, not just competent.

When you hash a password with bcrypt, you pass in a cost factor — an integer, usually between 10 and 14. This controls how many internal iterations run. The actual formula is 2^cost iterations. So a cost of 10 means 1,024 iterations. A cost of 12 means 4,096. A cost of 14 means 16,384.

That might not sound dramatic, but the practical effect is significant. On typical server hardware in 2026, cost 10 takes roughly 60–100ms to hash a single password. Cost 14 takes around a second or more. For a legitimate user logging in once, that's barely noticeable. For an attacker running millions of guesses per second? That multiplier destroys their throughput.

The beautiful thing is the adaptive design. As hardware gets faster, you bump the cost factor up by one. You don't change your code, you don't migrate to a new algorithm — you just increment a number and rehash on next login. The algorithm's inventors anticipated Moore's Law in 1999 and built a dial to compensate for it. That's still remarkable design thinking.

What about salting? Does bcrypt handle that automatically?

Yes, and this is one of bcrypt's underappreciated qualities.

A lot of older systems (and some embarrassingly recent ones) stored password hashes without salts. The problem: if two users have the same password, their hashes match. An attacker with a precomputed rainbow table — a giant lookup of common password hashes — can crack thousands of accounts in seconds.

Bcrypt generates a unique 128-bit random salt for every single hash computation and stores it as part of the hash output string. The final bcrypt output looks something like this:

$2b$12$EixZaYVK1fsbw1ZfbX3OXePaWxn96p36WQoeG6Lruj3vjPGga31lW

That string encodes everything: the algorithm version ($2b$), the cost factor (12), the 22-character salt, and the 31-character hash. You don't manage the salt separately. You don't forget to include it. It's baked in. This eliminates an entire category of implementation mistakes that have caused real breaches.

Why does deliberate slowness actually matter in 2026?

Modern GPUs are terrifying for password cracking. An RTX 4090 can compute MD5 hashes at something like 160 billion per second. SHA-256 is similar. If your database leaks and you used MD5 or plain SHA to store passwords, an attacker can try every word in every language, every common password, every combination of letters and numbers up to 8 characters — in minutes.

Against bcrypt at cost 12, that same GPU manages roughly 10,000–20,000 hashes per second. That's not a typo. Billions becomes thousands. A brute-force attack that takes minutes against MD5 takes years against bcrypt.

The reason is architectural. Bcrypt's Eksblowfish setup is memory-intensive in a way that doesn't parallelize well on GPU hardware. GPUs are brilliant at running thousands of identical simple operations simultaneously. Bcrypt's memory access patterns break that model. The algorithm was designed for CPUs, and it runs only slightly faster on GPUs than CPUs relative to its cost — which means the attacker's hardware advantage largely disappears.

How does it compare to Argon2, which won the Password Hashing Competition?

Argon2 is technically superior in some measurable ways. It's tunable across three dimensions — time cost, memory cost, and parallelism — which gives you finer control. The memory-hardness is more explicit, and it's designed to resist both GPU and ASIC attacks more aggressively than bcrypt.

But here's the practical reality in 2026: Argon2 is better on paper, bcrypt is battle-hardened in production. Bcrypt has been deployed, audited, attacked, and studied for over 25 years. Its failure modes are well-documented. Libraries implementing it exist for every language with mature test coverage. Most developers are more likely to misconfigure a newer algorithm than to hit a real-world limitation of bcrypt at a reasonable cost factor.

The honest answer: if you're starting a new project today, Argon2id with reasonable parameters is the best choice. If you're running bcrypt at cost 12 or above, you're not in danger. Don't drop everything to migrate.

What's the one actual weakness of bcrypt I should know about?

Password truncation. BCrypt only processes the first 72 bytes of input. If someone sets a password longer than 72 characters, everything after byte 72 is silently ignored. Two passwords that share the same first 72 characters will produce the same hash.

In practice, this rarely matters — most users don't type 72-character passwords. But if you're building a security-focused product and you want to support passphrases or high-entropy passwords without this limit, you can pre-hash the password with SHA-256 before passing it to bcrypt. Many libraries do this by default now, but check yours.

Where does 2FA fit into all this?

Password hashing and two-factor authentication solve different parts of the same problem.

Bcrypt protects you after a breach — when an attacker already has your database. Even if they crack a few weak passwords, the rest of your users are protected by the algorithm's cost.

2FA protects you before the breach — when an attacker has a correct password (via phishing, credential stuffing, or a breach from a different site) but doesn't have your users' second factor.

They're not competing. They're layers. A leaked database with bcrypt-hashed passwords at cost 12 means most accounts are safe. But for accounts where the user reused a password from a different breached site, 2FA is what keeps them safe. TOTP apps like Authy or Google Authenticator, or better yet hardware keys like YubiKeys, stop credential stuffing cold regardless of how strong or weak the underlying password is.

The real 2026 recommendation: bcrypt at cost 12+ for storage, plus TOTP or passkeys for authentication. These together make account takeover genuinely hard.

What cost factor should I actually use right now?

A practical benchmark: run bcrypt on your target hardware and find the cost that produces a 200–300ms hash time on a single CPU thread. In 2026 on typical cloud VMs, that's usually cost 12 for most hardware and sometimes 13 on faster instances.

Don't set it below 10. Don't obsess over hitting 14 if it makes your auth endpoints sluggish under load. The sweet spot is "slow enough to ruin an attacker's day, fast enough that real users don't notice."

And when you bump cost, you don't need to force-rehash all existing passwords at once. Just check the stored cost factor on every successful login and rehash transparently if it's below your current target. Most bcrypt libraries expose this as a needsRehash or equivalent function.

Final word: is bcrypt still worth using?

Yes. Not because it's the shiniest new option, but because it solves the problem it was designed for, it's nearly impossible to implement badly when you use a proper library, and its 25-year track record means the edge cases are documented rather than waiting to be discovered.

Use Argon2id if you're building something new and have the flexibility to tune it properly. Use bcrypt with confidence if it's already in your stack. Just make sure the cost factor isn't stuck at the 2008 default of 10, keep 2FA in the stack alongside it, and stop MD5-ing anything that matters.

The algorithms that stick around aren't always the most technically perfect ones. Sometimes they're the ones that fail in predictable, survivable ways — and by that measure, bcrypt in 2026 is still earning its keep.