Ctrl + K
Security10 min read

Bcrypt Explained

Understand how bcrypt protects passwords, why it is intentionally slow and learn best practices for secure password hashing.

Published: 2026-08-07

Bcrypt is one of the most widely used password hashing algorithms for securely storing user passwords. Unlike general-purpose hash functions such as MD5 or SHA-256, bcrypt was specifically designed for password hashing and includes built-in protections against brute-force attacks by intentionally making hashing computationally expensive.

Today, bcrypt remains a trusted choice for authentication systems, web applications and APIs. Its adaptive design allows developers to increase the computational cost as hardware becomes faster, helping maintain strong password protection over time.

What Is Bcrypt?

Bcrypt is a password hashing function based on the Blowfish cipher. It converts a plaintext password into a one-way hash that cannot realistically be reversed. During user authentication, the submitted password is hashed again and compared with the stored hash rather than storing or comparing the original password.

Why Password Hashing Matters

Storing plaintext passwords is one of the most serious security mistakes an application can make. If a database is compromised, attackers immediately gain access to every user's credentials. Password hashing ensures that even if hashes are stolen, recovering the original passwords remains extremely difficult.

  • Protects passwords if the database is leaked.
  • Makes brute-force attacks significantly slower.
  • Prevents accidental exposure of plaintext passwords.
  • Supports secure password verification.

Hashing vs Encryption

Hashing and encryption serve different purposes. Encryption is reversible with the appropriate key, while hashing is designed to be one-way. Passwords should almost always be hashed rather than encrypted because applications only need to verify passwords, not recover them.

HashingEncryption
One-way operationReversible with a key
Used for passwordsUsed for confidential data
Cannot recover original valueOriginal data can be decrypted

How Bcrypt Works

When a password is hashed with bcrypt, the algorithm first generates a random salt, combines it with the password and repeatedly performs expensive cryptographic operations. The resulting hash contains enough information for future password verification, including the salt and work factor.

The Role of Salts

A salt is a unique random value generated for every password before hashing. Even if two users choose the same password, their stored bcrypt hashes will be completely different because each uses a different salt.

Without SaltWith Salt
Identical passwords produce identical hashesEach password produces a unique hash
Vulnerable to rainbow tablesRainbow tables become impractical

What Is the Cost Factor?

One of bcrypt's defining features is its configurable cost factor, sometimes called the work factor. Increasing this value causes hashing to take longer, making password cracking substantially more expensive for attackers while allowing developers to strengthen security as hardware improves.

$2b$12$...

In bcrypt hashes, the number following the algorithm version indicates the cost factor used during hash generation.

Password Verification

Applications never decrypt bcrypt hashes because decryption is impossible. Instead, the user's entered password is hashed using the same parameters stored within the bcrypt hash. If the newly generated hash matches the stored value, authentication succeeds.

💡 Every password should receive its own randomly generated salt. Bcrypt handles salt generation automatically in standard implementations.
⚠️ Never store plaintext passwords alongside bcrypt hashes. The hash should be the only stored representation of a user's password.

Reading a Bcrypt Hash

A bcrypt hash contains more than the hashed password itself. It stores the algorithm version, the cost factor, the randomly generated salt and the resulting hash. This allows password verification without storing any additional metadata in the database.

$2b$12$KYVbZ5JFVfqu0oV98LnF5eTk4QTe2e4PQG7QNYfhumEpGdi/867AO

Although the hash appears to be a random string, every section has a specific meaning that bcrypt implementations automatically interpret during password verification.

Why Bcrypt Is Intentionally Slow

Unlike fast hashing algorithms, bcrypt is intentionally designed to require noticeable computation time. While this makes login requests only slightly slower for legitimate users, it dramatically increases the cost of brute-force attacks because attackers must spend the same amount of time calculating every password guess.

Bcrypt vs SHA-256

SHA-256 is an excellent cryptographic hash function for data integrity and digital signatures, but it was not designed for password storage. It is extremely fast, allowing attackers to test enormous numbers of password guesses every second. Bcrypt deliberately sacrifices speed to make password cracking significantly more difficult.

BcryptSHA-256
Designed for passwordsDesigned for general hashing
Intentionally slowVery fast
Automatic salt supportSalt must be added manually
Adaptive work factorFixed computational cost

Bcrypt vs Argon2

Argon2 is a newer password hashing algorithm and the winner of the Password Hashing Competition. It introduces memory-hard operations that make GPU and ASIC attacks even more expensive. However, bcrypt remains extremely popular because it has been thoroughly tested for decades and is supported by nearly every programming language and framework.

AlgorithmTypical Use
BcryptWidely deployed password hashing
Argon2Modern password hashing
PBKDF2Legacy and compliance-focused systems

Where Bcrypt Is Commonly Used

  • User authentication systems.
  • Web applications.
  • REST APIs.
  • Content management systems.
  • E-commerce platforms.
  • Identity providers.

Choosing a Cost Factor

There is no universally correct cost factor because it depends on available hardware and performance requirements. A good practice is to choose a value that allows password hashing to complete quickly enough for users while remaining expensive for attackers. As server hardware improves, applications can gradually increase the work factor for newly created or updated passwords.

Migrating Existing Passwords

Applications using weaker algorithms such as MD5 or SHA-1 should migrate users to bcrypt gradually. A common strategy is to verify the old hash during login and immediately replace it with a bcrypt hash after successful authentication, avoiding the need for every user to reset their password at once.

💡 If your authentication library supports automatic hash upgrades, you can transparently increase the bcrypt cost factor whenever users log in successfully.
⚠️ Do not invent your own password hashing scheme by combining multiple hash functions. Use well-tested bcrypt implementations provided by trusted cryptographic libraries.

Common Bcrypt Mistakes

Many password security problems are caused not by weaknesses in bcrypt itself, but by incorrect implementation. Fortunately, most mistakes are easy to avoid by following established security practices and using trusted cryptographic libraries.

  • Hashing passwords with SHA-256 instead of bcrypt.
  • Using an outdated or very low cost factor.
  • Attempting to generate salts manually.
  • Truncating or modifying stored bcrypt hashes.
  • Storing plaintext passwords for debugging.
  • Using homemade cryptographic implementations instead of established libraries.

Performance Considerations

Because bcrypt is intentionally computationally expensive, it consumes noticeably more CPU resources than general-purpose hash functions. Authentication systems should expect password verification to take significantly longer than ordinary hashing operations. This additional processing time is an intentional security feature rather than a performance flaw.

Large authentication systems often benchmark bcrypt performance periodically and increase the work factor only when their infrastructure can comfortably support the additional computational cost.

Bcrypt in Modern Frameworks

Nearly every modern programming language provides mature bcrypt libraries. Popular web frameworks typically integrate bcrypt directly or through authentication packages, allowing developers to hash and verify passwords without implementing any cryptographic logic themselves.

PlatformTypical Support
Node.jsbcrypt and bcryptjs packages
Pythonbcrypt library
PHPpassword_hash() and password_verify()
JavaSpring Security and jBCrypt
.NETASP.NET Identity

Best Practices

  • Use bcrypt only for password hashing, not for general-purpose hashing.
  • Choose an appropriate work factor for your hardware.
  • Use well-maintained cryptographic libraries instead of implementing bcrypt yourself.
  • Allow bcrypt to generate a unique random salt for every password.
  • Upgrade the cost factor gradually as hardware becomes faster.
  • Combine bcrypt with strong password policies and multi-factor authentication where appropriate.
💡 A strong hashing algorithm cannot compensate for weak passwords. Encourage users to create long, unique passwords and consider supporting passphrases and password managers.
⚠️ Bcrypt protects stored passwords, but it does not prevent phishing, credential reuse or stolen session tokens. Password hashing should be only one layer of a comprehensive security strategy.

Frequently Asked Questions

Is bcrypt encryption?

No. Bcrypt is a one-way password hashing algorithm, not an encryption algorithm. Passwords cannot be decrypted from bcrypt hashes.

Why is bcrypt slower than SHA-256?

Bcrypt is intentionally designed to be computationally expensive so that brute-force attacks become much slower and more costly for attackers.

Does bcrypt automatically generate salts?

Yes. Standard bcrypt implementations automatically generate and store a unique random salt for every password hash.

Should I still use bcrypt today?

Yes. Bcrypt remains a secure and widely recommended password hashing algorithm. Although newer algorithms such as Argon2 are available, bcrypt continues to be an excellent choice for most applications.

Can I compare bcrypt hashes directly?

No. Password verification should always be performed using the verification function provided by your bcrypt library, which hashes the entered password using the stored parameters and safely compares the results.

Helpful Security Tools

A Bcrypt Generator lets you experiment with bcrypt hashes and different work factors, a Password Generator helps create strong random passwords suitable for bcrypt storage, a Hash Generator demonstrates how general-purpose hashing algorithms differ from password hashing, an Entropy Calculator estimates password strength, and a Secure Random Generator produces cryptographically secure random values for security-related applications.

Conclusion

Bcrypt has been protecting user passwords for decades and remains one of the most trusted password hashing algorithms available. Its automatic salting, adaptive work factor and intentionally slow computation make it highly resistant to brute-force attacks while remaining practical for real-world authentication systems. By combining bcrypt with strong password policies, secure authentication workflows and modern security practices, developers can significantly reduce the risk of credential compromise and build applications that remain resilient as computing hardware continues to evolve.