What is bcrypt and how does it work?

Bcrypt is a password hashing function introduced in 1999 by Niels Provos and David Mazières, based on the Blowfish cipher. It takes a password as input and produces a fixed-size 60-character hash string in the format $2a$[cost]$[22 char salt][31 char hash]. Bcrypt is an adaptive function, meaning you can increase the computational cost over time as hardware gets faster by adjusting the cost factor (work factor). Each increment of the cost factor doubles the time required to compute the hash—for example, cost 10 equals 2 to the power of 10 (1024) iterations. Bcrypt automatically includes a random salt in the hash output, so you do not need to store salt separately. The algorithm uses key stretching through its expensive key setup phase, running through multiple rounds of the Blowfish cipher with both the salt and password to produce the final hash. This intentional slowness makes brute-force attacks computationally expensive, protecting passwords even if attackers obtain the database. Bcrypt outputs 184 bits of cryptographic data and has been battle-tested for over 20 years in millions of production systems worldwide.

Why should I use bcrypt for password hashing?

Bcrypt is specifically designed for password hashing with built-in protection against brute-force attacks. Unlike fast hash functions like SHA-256 or MD5 which can compute billions of hashes per second on modern hardware, bcrypt is intentionally slow—this slowness is a security feature, not a bug. When an attacker steals your password database, they must spend significant computational resources to crack each password. Bcrypt automatically includes a random salt in every hash, preventing rainbow table attacks where attackers use precomputed hashes of common passwords. The adaptive cost factor means you can increase security over time as computers get faster, simply by incrementing the cost parameter without changing the algorithm. Bcrypt is battle-tested since 1999 and is used by millions of websites and applications including Ruby on Rails (default), Django, Laravel, Express.js, and Flask. It has withstood decades of cryptanalysis without being broken. While newer algorithms like Argon2 are generally preferred for new systems, bcrypt remains secure and is perfectly acceptable for existing applications. Bcrypt handles passwords up to 72 bytes and truncates longer passwords, which is sufficient for most use cases. This tool processes passwords entirely client-side, ensuring your passwords never leave your device.

What is the cost factor and how do I choose it?

The cost factor (also called work factor) controls how computationally expensive bcrypt hashing is. It ranges from 4 to 31, with each increment doubling the time required. Cost factor 10 means 2 to the power of 10 equals 1024 iterations. Cost factor 12 means 2 to the power of 12 equals 4096 iterations. For 2024, cost factor 10 is the default and provides a good balance between security and performance—it takes approximately 100-200 milliseconds to hash one password on modern hardware. Cost factor 12 is recommended for higher security requirements, taking around 400-800 milliseconds per hash. Cost factor 14 or higher is used for maximum security or extremely sensitive systems, but may impact user experience during login. Choosing the right cost factor depends on your security requirements and acceptable login delay—users typically accept 200-500ms login times. As computers get faster over time, gradually increase the cost factor every few years to maintain security. For example, cost 10 was sufficient in 2010, cost 12 became standard around 2015-2020, and cost 14 may become recommended by 2025-2030. Test hashing performance on your production hardware and choose the highest cost factor that keeps login times acceptable. This tool uses cost factor 10 by default for broad compatibility, but you can adjust it based on your security needs.

How does bcrypt compare to Argon2 and scrypt?

Bcrypt, Argon2, and scrypt are all designed for password hashing with different strengths and use cases. Bcrypt (1999) is the oldest, battle-tested for over 20 years, uses moderate memory (4KB per hash), CPU-bound, and is widely supported across all platforms and languages. It is still secure but uses less memory than modern alternatives, making it somewhat vulnerable to GPU-based attacks compared to memory-hard algorithms. Scrypt (2009) is more memory-intensive than bcrypt (configurable from KB to GB), resistant to GPU attacks due to high memory requirements, and is used in some cryptocurrencies. However, it is less widely supported than bcrypt and can be complex to configure properly. Argon2 (2015) won the Password Hashing Competition, is the recommended choice for new systems, offers three variants (Argon2i for side-channel resistance, Argon2d for maximum GPU resistance, Argon2id for both—recommended), is highly configurable for memory, CPU, and parallelism, and is resistant to both GPU and ASIC attacks. The recommendation is to use Argon2id for new applications and maximum security, use bcrypt for existing systems or when maximum compatibility is needed, and use scrypt for cryptocurrency-related applications or when memory-hardness is critical. Bcrypt remains secure for most applications and is perfectly fine to continue using in existing systems. However, for greenfield projects starting in 2024, Argon2id is the gold standard.

Does bcrypt include a salt automatically?

Yes! Bcrypt automatically generates a random 128-bit (16-byte) salt and includes it directly in the hash output. This is one of bcrypt's key features—you do not need to generate, store, or manage salts separately. The bcrypt hash format is $2a$10$saltsaltsaltsaltsalthashhashhashhashhashhashhash where the salt is the 22-character portion after the cost factor, and the hash is the final 31 characters. When you verify a password, the bcrypt library automatically extracts the salt from the stored hash and uses it to hash the provided password for comparison. This automatic salt handling prevents rainbow table attacks where attackers use precomputed hashes of common passwords. Every password gets a unique random salt, so even if two users have the same password (like "password123"), their bcrypt hashes will be completely different. The salt is encoded using a custom base64-like alphabet (using characters a-z, A-Z, 0-9, and . /) to fit the hash format. You never need to manually extract or use the salt—just store the entire 60-character hash string and use bcrypt's verify function to check passwords. This is different from some other algorithms like Argon2 where you sometimes need to store salt separately, or raw SHA hashes that require manual salt management. Bcrypt's integrated salt handling makes it simpler and less error-prone for developers.

Can I reverse a bcrypt hash to get the original password?

No, bcrypt hashes cannot be reversed or decrypted because bcrypt is a one-way cryptographic hash function, not encryption. Bcrypt is mathematically designed to be computationally infeasible to reverse—the algorithm destroys information during the hashing process through multiple rounds of the Blowfish cipher, key stretching, and compression. Unlike encryption which preserves information and can be decrypted with a key, hashing is intentionally irreversible. The only way to find the password for a bcrypt hash is to use brute force—trying millions or billions of password guesses, hashing each one with bcrypt, and comparing the result to the target hash. However, bcrypt's intentional slowness makes this extremely time-consuming. At cost factor 10, modern hardware can test only about 5-10 passwords per second per CPU core, meaning a random 8-character password with uppercase, lowercase, and numbers (about 218 trillion possibilities) would take thousands of years to crack through brute force. This is exactly why bcrypt is secure for passwords—even if attackers steal your database, they cannot extract passwords in reasonable time. For weak passwords like "password123" or "qwerty", attackers can use dictionary attacks with common passwords, which is why strong passwords are still essential. Bcrypt protects against technical attacks but cannot protect against users choosing weak passwords. The 60-character hash is a cryptographic fingerprint that proves you knew the password but does not reveal what it was.

How do I verify a password against a bcrypt hash?

To verify a password against a bcrypt hash, use the bcrypt library's compare or verify function available in your programming language. Do not attempt to hash the password manually and compare strings—bcrypt handles this for you. In Node.js with bcrypt library, use bcrypt.compare(password, hash) which returns true if the password matches, false otherwise. In Python with bcrypt library, use bcrypt.checkpw(password.encode("utf-8"), hash) which returns True or False. In PHP, use password_verify(password, hash) which returns true or false. In Ruby on Rails, use BCrypt::Password.new(hash) == password which returns true or false. In Java with Spring Security, use BCryptPasswordEncoder().matches(password, hash). The verification process works by extracting the salt and cost factor from the stored hash (they are embedded in the hash string), using that same salt and cost to hash the provided password, then comparing the newly computed hash with the stored hash. If they match exactly, the password is correct. This comparison happens in constant time to prevent timing attacks. The beauty of bcrypt is that you only need to store the 60-character hash string—it contains everything needed for verification including the algorithm version ($2a$), cost factor (10), salt (22 chars), and the hash itself (31 chars). Never compare bcrypt hashes using simple string equality in your application code—always use the library's verify function which handles constant-time comparison and proper hash validation.

Why is bcrypt intentionally slow?

Bcrypt is intentionally slow because slowness is a security feature for password hashing, not a performance bug. When a user logs in, hashing their password takes 100-500 milliseconds—barely noticeable and completely acceptable for human interaction. However, when an attacker steals your password database and tries to crack passwords through brute force, that same 100-500ms delay applies to every single guess. At cost factor 10, an attacker can test only about 5-10 passwords per second per CPU core. To crack a random 8-character password with mixed case and numbers (about 218 trillion possibilities), they would need about 1.3 million CPU-years of computation time. Modern GPUs can compute billions of SHA-256 hashes per second, allowing attackers to crack simple passwords in minutes or hours. But bcrypt's memory access patterns and computational complexity make GPU acceleration much less effective—GPUs might be only 10-100x faster than CPUs for bcrypt, not 1000x like with SHA-256. This levels the playing field between defenders (who hash one password per login) and attackers (who must hash millions or billions during cracking). As computers get faster, you can increase the cost factor to maintain this security margin—each increment doubles the time, keeping pace with Moore's Law. The adaptive nature means bcrypt remains secure even as hardware improves. Fast hashing algorithms like MD5 or SHA-256 are perfect for file integrity and checksums but terrible for passwords precisely because they are too fast. Bcrypt, Argon2, and scrypt are deliberately slow to make password cracking economically and computationally infeasible.

Is my password safe when using this bcrypt tool?

Yes, your password is completely safe! This bcrypt tool processes all data locally in your browser using JavaScript—nothing is sent to any server. Your password, salt, and generated hash never leave your device, ensuring complete privacy. The bcrypt hashing algorithm is loaded into your browser as JavaScript code, then all computation happens on your local machine. You can verify this by opening your browser's developer tools and checking the Network tab—you will see no requests are made when hashing. You can even disconnect from the internet after loading the page and the tool will continue working. This client-side processing makes the tool safe for highly sensitive passwords, production system credentials, and personal accounts. However, remember that bcrypt is a one-way hash—once you generate a hash, you cannot reverse it to get your password back. Store your password securely before hashing if you need to remember it. The bcrypt hash itself can be safely stored in databases and shared with other systems because it cannot be reversed to reveal the original password. Even if someone intercepts your hash, they cannot extract your password from it. Always use HTTPS-secured websites (like this one) to prevent man-in-the-middle attacks when loading the tool, even though processing is local. For production systems with maximum security requirements, consider using offline command-line bcrypt tools or verify the JavaScript source code is truly client-side. Bcrypt's 20+ year track record and use by millions of websites makes it one of the most trusted password hashing functions available.

Which frameworks and systems use bcrypt by default?

Bcrypt is the default or recommended password hashing algorithm in many popular frameworks and systems, proving its widespread trust and adoption. Ruby on Rails uses bcrypt via the has_secure_password method in Active Model, which is the standard for password authentication in Rails applications. Django recommends bcrypt as the most secure hasher and many Django projects use django-bcrypt or the built-in BCryptSHA256PasswordHasher. Laravel uses bcrypt as the default password hashing algorithm through the Hash facade and Illuminate\\Hashing\\BcryptHasher. Express.js and Node.js applications commonly use the bcrypt or bcryptjs npm packages, which have over 3 million weekly downloads combined. Flask applications often use Flask-Bcrypt extension or the bcrypt library directly for password hashing. Devise (popular Rails authentication gem) uses bcrypt by default for all password operations. WordPress began using bcrypt-based hashing with the phpass library for improved security over older MD5 hashes. Many enterprise systems including corporate identity management, healthcare applications requiring HIPAA compliance, financial systems, and government platforms use bcrypt for password protection. Some cryptocurrencies and blockchain systems use bcrypt or variants for proof-of-work algorithms. The bcrypt algorithm is standardized and implemented consistently across virtually all programming languages—Python, JavaScript, Java, C#, Go, Rust, PHP, Ruby, and more all have mature, well-tested bcrypt libraries. This universal availability makes bcrypt a safe choice for cross-platform applications and microservices architectures where different components may use different languages.