Security

What Is Bcrypt? How Password Hashing Actually Works

Every time you create a password on a website, that password needs to be stored — but storing it in plain text would be catastrophic if the database was ever leaked. Bcrypt is one of the algorithms designed to make stored passwords secure even when attackers get hold of the database. Here's how it works and why it matters.

What Is Bcrypt?

Bcrypt is a password hashing function created by Niels Provos and David Mazières in 1999, based on the Blowfish cipher. It was designed specifically for one purpose: storing passwords securely. Unlike general-purpose hash functions, bcrypt is intentionally slow and computationally expensive, making it resistant to brute-force attacks even when a database of hashed passwords is stolen.

You can generate and verify bcrypt hashes using our browser-based bcrypt generator — no installation required.

Why Not Just Use SHA-256?

SHA-256 is a general-purpose cryptographic hash function designed to be fast. Very fast. A modern GPU can compute billions of SHA-256 hashes per second. If an attacker gets a database of SHA-256 password hashes, they can try billions of guesses per second until they find matches — and most common passwords will be found within minutes or hours.

MD5 is even worse and should never be used for passwords under any circumstances. Even SHA-512 is too fast for password storage.

Bcrypt is deliberately slow by design. With cost factor 10, a single bcrypt hash takes about 100ms on modern hardware. That's ~10 hashes per second — billions of times slower than SHA-256. An attacker who steals a bcrypt database can only try a handful of passwords per second per core.

How Bcrypt Works

Bcrypt does three things that plain hashes don't:

Salt: Bcrypt automatically generates a unique random salt for each hash. The salt is embedded in the output hash. This means two users with the same password will have completely different hashes, and rainbow table attacks (precomputed hash dictionaries) are impossible.

Adaptive cost: The cost factor controls how many rounds of key scheduling are performed. Each increment doubles the work required. This allows the cost to be increased over time as hardware gets faster, keeping bcrypt secure as computing power grows.

Self-contained output: The bcrypt output contains the version, cost factor, salt, and hash in a single 60-character string. Everything needed to verify a password is in the hash itself — no separate salt storage needed.

Choosing the Right Cost Factor

OWASP recommends cost factor 10 as the minimum for most applications in 2026 — this produces a hash in about 100ms on a modern server. Cost 12 takes about 400ms and is appropriate for high-security applications where slightly slower login is acceptable.

The right cost is the highest value your server can handle within an acceptable login time — typically targeting 100–300ms. As hardware improves, you should periodically increase the cost factor and re-hash passwords when users next log in.

Never use a cost factor below 8 in production. For testing and development, cost 8 is fine to keep things fast.

Reading a Bcrypt Hash

A bcrypt hash looks like: $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

Breaking it down: $2b$ is the bcrypt version (2b is current). $10$ is the cost factor. The next 22 characters (N9qo8uLOickgx2ZMRZoMye) are the base64-encoded salt. The remaining 31 characters are the hash. The full output is always exactly 60 characters.

Bcrypt vs Argon2 vs scrypt

All three are good choices for password hashing. Bcrypt is the most widely supported and has the longest security track record. Argon2 (winner of the Password Hashing Competition in 2015) is the modern recommendation — it's memory-hard, making it more resistant to GPU and ASIC attacks. scrypt is also memory-hard and a solid choice.

If you're starting a new project, Argon2id is the current best practice recommendation from OWASP. For existing systems using bcrypt, there's no urgent reason to migrate — bcrypt remains secure when used correctly.

In all cases: never use MD5, SHA-1, or plain SHA-256/512 for passwords. Use a dedicated password hashing function.

Related Articles