Security

What Is Bcrypt? How Password Hashing Actually Works

2026-03-11· 5 min read· Steven Adams · Last reviewed: March 2026

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.

In This Guide

  1. What Is Bcrypt?
  2. Why Not Just Use SHA-256?
  3. How Bcrypt Works
  4. The Cost Factor
  5. Reading a Bcrypt Hash
  6. Bcrypt vs Argon2 vs scrypt

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

What bcrypt Does and Why It Was Created

bcrypt is a password hashing algorithm designed specifically for storing passwords securely. It was created in 1999 by Niels Provos and David Mazières, who recognised that general-purpose cryptographic hash functions like MD5 and SHA-1 — while fast for their intended purposes — were dangerously fast for password hashing. Speed is the enemy of password security: a fast algorithm lets attackers try billions of password guesses per second. bcrypt was designed to be deliberately slow, with the speed adjustable through a cost factor parameter.

bcrypt is based on the Blowfish block cipher and includes a built-in salt (random data mixed in before hashing). This salt ensures that two users with the same password will have completely different bcrypt hashes, making precomputed "rainbow table" attacks useless against bcrypt-protected databases.

The Cost Factor: Adjustable Slowness

bcrypt's cost factor (also called the work factor or rounds) is a number typically between 10 and 14 that controls how computationally expensive hashing is. A cost factor of 10 means the hashing process runs 2^10 = 1,024 iterations. A cost factor of 12 means 2^12 = 4,096 iterations. This makes bcrypt adaptive — as computers get faster over time, you can increase the cost factor to maintain the same effective resistance to brute force attacks. The current recommended cost factor is 12 for most applications, and 14 or higher for particularly sensitive systems. At cost factor 12, bcrypt takes approximately 250 milliseconds on a modern CPU — fast enough for user logins but slow enough to make mass cracking impractical.

bcrypt vs Other Password Hashing Algorithms

bcrypt competes with scrypt and Argon2 for modern password hashing. scrypt adds memory-hardness (requiring large amounts of RAM, not just CPU time) making it more resistant to GPU-based cracking. Argon2 (the winner of the 2015 Password Hashing Competition) supports both CPU-hardness and memory-hardness and is considered the most modern choice. For new applications, Argon2id is the current recommendation. bcrypt remains very widely used and is considered secure at appropriate cost factors — you will encounter it in many existing codebases and it is perfectly acceptable for protecting passwords today.

Frequently Asked Questions

Can bcrypt hashes be reversed to get the original password? No — bcrypt is a one-way function. There is no mathematical way to reverse a bcrypt hash to get the original password. Attackers crack bcrypt hashes by trying many password guesses, hashing each one, and checking if it matches — the high cost factor makes this slow. bcrypt cannot be "decrypted"; it can only be brute-forced.

Why does bcrypt have a 72-character password limit? bcrypt internally processes only the first 72 bytes of a password due to the underlying Blowfish cipher's design. Passwords longer than 72 characters have their extra characters silently ignored. For most users this is not a concern, but if you use very long passphrases, consider pre-hashing them with SHA-256 before bcrypt, or switching to Argon2 which has no such limit.

How do I use bcrypt to verify a password? You never store the original password — only the bcrypt hash. To verify, run bcrypt on the entered password with the same salt (extracted from the stored hash) and compare the result to the stored hash. Most bcrypt libraries handle this automatically with a verify() or checkpw() function. Our bcrypt tool lets you hash and verify passwords directly in your browser.