Bcrypt Explained
Understand how bcrypt protects passwords, why it is intentionally slow and learn best practices for secure password hashing.
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.
| Hashing | Encryption |
|---|---|
| One-way operation | Reversible with a key |
| Used for passwords | Used for confidential data |
| Cannot recover original value | Original 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 Salt | With Salt |
|---|---|
| Identical passwords produce identical hashes | Each password produces a unique hash |
| Vulnerable to rainbow tables | Rainbow 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.
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/867AOAlthough 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.
| Bcrypt | SHA-256 |
|---|---|
| Designed for passwords | Designed for general hashing |
| Intentionally slow | Very fast |
| Automatic salt support | Salt must be added manually |
| Adaptive work factor | Fixed 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.
| Algorithm | Typical Use |
|---|---|
| Bcrypt | Widely deployed password hashing |
| Argon2 | Modern password hashing |
| PBKDF2 | Legacy 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.
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.
| Platform | Typical Support |
|---|---|
| Node.js | bcrypt and bcryptjs packages |
| Python | bcrypt library |
| PHP | password_hash() and password_verify() |
| Java | Spring Security and jBCrypt |
| .NET | ASP.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.
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.