What Is Bcrypt and How Does Password Hashing Work?

Why You Cannot Store Plain Passwords

If a database is compromised, plain-text passwords give attackers immediate access to every account — not just on your platform, but everywhere users reused those passwords. This is why every major data breach that exposes passwords triggers mass account takeovers across the internet.

The solution is hashing: storing a one-way transformation of the password instead of the password itself. When a user logs in, you hash their input and compare it to the stored hash — if they match, the password is correct. You never need to store the original.

Why MD5 and SHA Are Insufficient for Passwords

MD5, SHA-1, and SHA-256 are cryptographic hash functions designed for speed. This is their downfall for password storage. A modern GPU-based cracking rig can test:

• Over 60 billion MD5 hashes per second
• Over 10 billion SHA-256 hashes per second

At these speeds, every 8-character password (even with all character types) can be cracked in hours. Even with a random salt (a unique value mixed into each hash to prevent rainbow table attacks), the raw speed of SHA-256 makes brute force practical for weak passwords.

The fundamental problem is that MD5 and SHA are optimised for speed — they were designed to hash large files and data streams quickly, not to resist password-guessing attacks.

How Bcrypt Solves This

Bcrypt was designed in 1999 by Niels Provos and David Mazières specifically for password hashing. Its key properties are:

Intentional slowness: Bcrypt is designed to be computationally expensive. The algorithm runs multiple rounds of the Blowfish cipher, making each hash calculation slow — typically 50–300ms depending on the cost factor. A GPU can compute only a few thousand bcrypt hashes per second, compared to billions for MD5.

Adaptive work factor: The "cost factor" or "rounds" parameter controls how slow the hash is. As hardware gets faster, you can increase the cost factor to maintain the same effective cracking resistance. A cost factor of 10 in 2010 can be increased to 12 in 2026 without changing the algorithm.

Built-in salting: Bcrypt automatically generates a cryptographically random 128-bit salt for each hash. The salt is stored as part of the hash string, so you don't need to manage it separately. Two identical passwords always produce different bcrypt hashes.

Fixed-length output: A bcrypt hash is always 60 characters long, regardless of input password length, making database schema simple.

Reading a Bcrypt Hash

A bcrypt hash looks like this:

$2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/lewkGCm3q6XGBHP5O

Breaking this down:

• $2b$ — Algorithm version (2b is the current standard; 2a and 2y are older versions)
• 12$ — Cost factor (2¹² = 4096 rounds)
• Next 22 characters — The base64-encoded salt
• Remaining 31 characters — The base64-encoded hash

When verifying a password, the algorithm extracts the version, cost factor, and salt from the stored string, uses them to hash the input password, and compares the result to the stored hash portion.

Choosing the Right Cost Factor

The cost factor should be set so that hashing takes approximately 100–300ms on your server hardware. This is slow enough to resist brute-force attacks but fast enough that legitimate login requests don't cause noticeable delays.

• Cost 10: ~100ms on modern hardware — minimum recommended
• Cost 12: ~400ms — good balance for most applications
• Cost 14: ~1600ms — for high-security applications

Test on your actual server and adjust accordingly. As hardware improves over the years, plan to periodically increase the cost factor and re-hash passwords at next login.

Alternatives to Bcrypt

Bcrypt is the most widely used password hashing algorithm, but there are two strong alternatives:

• Argon2: Won the 2015 Password Hashing Competition and is considered the current state of the art. It resists both GPU and ASIC attacks more effectively than bcrypt. Use Argon2id for new projects if your language/framework supports it.
• scrypt: Designed to be memory-hard, making it expensive to run in parallel on GPUs. Good alternative if Argon2 is not available.
• PBKDF2: FIPS-approved and widely supported. Less resistant to GPU attacks than bcrypt or Argon2 but acceptable when configured with a high iteration count (100,000+ for SHA-256).

You can experiment with bcrypt hashing using our free Bcrypt Hash Generator — useful for testing and understanding the algorithm before implementing it in your application.

Frequently Asked Questions

Why can't you use MD5 or SHA-256 to store passwords?

MD5 and SHA-256 are designed to be fast — they can compute billions of hashes per second on modern hardware. This makes brute-force attacks feasible. Bcrypt is intentionally slow, making it impractical to test billions of guesses, even with powerful hardware.

What is the bcrypt cost factor?

The cost factor (also called work factor or rounds) controls how slow the hashing is. A cost factor of 10 means 2^10 = 1024 rounds of computation. A factor of 12 means 4096 rounds. Higher is slower and more secure. Aim for a cost factor that takes 100–300ms on your server hardware.

Can two identical passwords produce different bcrypt hashes?

Yes — bcrypt uses a random salt, which means the same password hashed twice will produce two completely different hash strings. This is by design. When verifying, bcrypt extracts the salt from the stored hash and uses it to hash the input password for comparison.

Is bcrypt suitable for hashing non-password data?

No. Bcrypt is specifically designed for passwords — it is intentionally slow and not suitable for hashing large volumes of data or non-secret data like file checksums. Use SHA-256 or SHA-3 for those purposes. Our Hash Generator covers SHA and MD5 use cases.