Bcrypt Explained: How Password Hashing Really Works

Bcrypt password hashing works by making the attacker's job expensive: it runs a password through a deliberately slow, salted algorithm, so each guess against a stolen hash costs real compute time. That slowness is a feature — and it's controlled by a single number, the cost factor, that most tutorials tell you to copy without ever explaining how to choose it.

Here's the claim this guide will back up: the cost factor matters more than almost any other decision you'll make about password storage, and the right way to pick it is as a time budget measured on your own hardware — not a number inherited from a tutorial written when servers were a fraction of their current speed.

Why fast hashes fail for passwords

Let's steelman the popular myth first, because it's built on a true fact: SHA-256 is not broken. For file checksums, digital signatures, and data integrity, it's exactly the right tool.

For passwords? No.

The problem isn't cryptographic weakness — it's speed. SHA-256 was engineered to be fast, and modern GPUs can attempt billions of SHA-256 guesses per second against a leaked hash. Human passwords occupy a depressingly small search space: most fall inside wordlists and mutation rules that crackers have refined for decades. Pair a fast hash with a predictable password and the math ends badly — a fast hash protects a leaked password for minutes, not years.

Password hashing inverts the usual engineering goal. You want the slowest acceptable function, not the fastest. That is the entire reason bcrypt exists.

How bcrypt actually works

Bcrypt was designed in 1999 by Niels Provos and David Mazières, built on the Blowfish cipher's expensive key-setup phase. It does three things a plain hash doesn't:

1. It's tunably slow. The cost factor sets how many times the internal setup repeats — and it's logarithmic, so cost 10 means 2^10 = 1,024 iterations, and each +1 doubles the work.
2. It salts automatically. Every hash gets a fresh random 128-bit salt, so two users with the same password get completely different hashes, and precomputed rainbow tables become useless.
3. It packages everything. Version, cost, salt, and hash travel together in one 60-character string.

Read one like a label. Take $2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW:

This anatomy answers the question that confuses almost everyone the first time: "where do I store the salt?" You don't. It's already in the hash, which is why a bcrypt compare check needs only the password and the stored string — it reads the salt and cost out of the hash, re-computes, and compares.

The cost factor is a time budget, not a magic number

Most bcrypt examples on the internet use cost 10, and most developers ship it unchanged. But 10 wasn't handed down as a security constant — it was a reasonable default for hardware that is now many times slower than what you deploy on. Hardware roughly doubles in capability every few years; a logarithmic cost factor is designed to climb with it. A fixed "10" quietly loses ground every year it goes unreviewed.

So stop asking "what number should I use?" and ask "how long should one hash take?" The working answer: around a quarter of a second on your production hardware. At ~250 ms, a legitimate login feels instant, but an attacker's guess rate collapses from billions per second to single-digit thousands per second per machine — a slowdown on the order of a million times.

The procedure takes five minutes:

1. Generate a hash at cost 10 with a bcrypt hash generator and note how long it takes.
2. Step the cost up — 11, 12, 13 — timing each one. Each step should roughly double the time.
3. Ship the highest cost that stays inside your latency budget, and put a calendar note to re-benchmark in a year or two.

It depends on your hardware — that's precisely the point. A number chosen by measurement ages well; a number copied from a tutorial ages like the tutorial.

Two myths worth retiring

"Bcrypt encrypts the password." No. Encryption is reversible with a key; bcrypt is a one-way function with no key and no way back. Nobody — not you, not your database admin — can recover the password from the hash. Verification is re-hashing, never reversing.

"I should pre-hash long passwords myself." Careful — here's a genuine sharp edge instead of a myth: bcrypt only reads the first 72 bytes of input, so characters beyond that are silently ignored. Some systems work around it by pre-hashing with SHA-256 first, but done naively that can introduce its own subtle problems (raw-byte outputs can contain null bytes that truncate input in some implementations). If you need to handle very long passphrases, use a library that documents this path explicitly rather than improvising.

When bcrypt isn't the answer

Fair is fair: if you're designing a brand-new system in 2026, Argon2id is the first recommendation in current guidance, because its memory-hardness blunts GPU attacks in a way bcrypt's design doesn't. But "newer exists" is not "bcrypt failed." Twenty-five years of analysis, universal library support, and no practical breaks make well-configured bcrypt a defensible choice — and migrating an existing bcrypt system to something else is rarely the highest-value security work on anyone's list. Raising a cost factor of 10 to 12, on the other hand, is a one-line change.

Try it yourself

Everything above is testable in your browser in under a minute, with nothing uploaded. And if you're weighing bcrypt against the other algorithms for a different job, MD5 vs SHA-256 vs Bcrypt maps each one to its right use.

• Bcrypt Hash Generator — hash a test password at different cost factors and feel the doubling yourself.
• Bcrypt Compare — verify a password against a hash and see salt-embedding in action.
• SHA256 Generator — compare how instant a fast hash is, and understand why that speed is the problem.
• Password Generator — because the other half of this equation is passwords worth protecting.

Conclusion

Bcrypt's job is to sell time: every doubling of the cost factor doubles what an attacker pays per guess. The algorithm handles the salt, the format carries its own metadata, and the only decision genuinely left to you is the time budget. Measure a quarter-second on your own hardware, set the cost accordingly, and revisit it as machines get faster. That one measured number does more for your users' passwords than any amount of exotic algorithm shopping.