Why Password Hashing Is Essential
Passwords remain the primary authentication mechanism for the vast majority of digital services, from email and banking to social media and enterprise applications. When users create accounts, they trust your application to protect their passwords. If that trust is violated — whether through a database breach, insider threat, or misconfigured server — the consequences can be devastating for both users and the organization.
Storing passwords in plaintext is an unforgivable security failure, yet it still happens in practice. When a plaintext password database is leaked, attackers gain immediate access to every account. Even storing passwords with a fast cryptographic hash like SHA-256 is insufficient, because attackers can test billions of password guesses per second using GPUs and specialized hardware. The solution is to store passwords using a slow, adaptive hashing algorithm specifically designed to resist brute-force attacks.
Bcrypt is precisely such an algorithm. Designed by Niels Provos and David Mazières in 1999, bcrypt incorporates a salt and an adjustable cost factor to make password hashing computationally expensive. The salt ensures that identical passwords produce different hashes, preventing rainbow table attacks. The cost factor allows the algorithm to be slowed down over time as hardware improves, maintaining security for decades.
- Plaintext password storage is a critical security failure
- Fast hashes like SHA-256 are vulnerable to GPU brute-forcing
- Bcrypt is designed to be slow and resistant to hardware acceleration
- Salts prevent rainbow table and precomputation attacks
- Adjustable cost factor adapts to increasing hardware power
How Bcrypt Works Under the Hood
Bcrypt is based on the Blowfish cipher and uses a modified key schedule that makes the hashing process expensive in both time and memory. Understanding its internal mechanics helps developers appreciate why bcrypt is so effective and how to configure it correctly.
When a password is hashed with bcrypt, the algorithm first generates a random salt — typically 16 bytes of cryptographically secure random data. The salt is combined with the password and fed into the Eksblowfish key setup, which runs for a number of rounds determined by the cost factor. The cost factor is an exponent: a cost of 10 means 2^10 (1024) rounds, while a cost of 12 means 2^12 (4096) rounds. Each increment doubles the computation time.
After the key setup completes, the algorithm encrypts a well-known constant string using Blowfish in ECB mode with the derived key. The resulting ciphertext, combined with the salt, cost factor, and algorithm identifier, forms the bcrypt hash string. This string contains everything needed to verify a password later: the cost factor tells the verifier how many rounds to run, and the salt ensures the same setup can be reproduced.
The output format is standardized and self-describing. A bcrypt hash looks like $2b$12$... where $2b$ identifies the algorithm and version, $12$ is the cost factor, and the remaining characters encode the salt and the hash value. When verifying a password, the verifier extracts the cost and salt from the stored hash, re-runs the algorithm with the submitted password, and compares the results.
- Generates a random 16-byte salt for each password
- Cost factor determines the number of rounds (2^cost)
- Uses modified Blowfish key schedule for expensive hashing
- Self-describing output string includes algorithm, cost, salt, and hash
- Verification extracts parameters from stored hash and re-runs algorithm
How to Use the Bcrypt Generator
Our Bcrypt Generator and Verifier tool runs entirely in your browser using the bcryptjs library loaded via CDN within an iframe. This client-side architecture ensures that passwords you enter for testing or generating hashes are never transmitted to any server, eliminating the risk of exposure through network interception or server logs.
To generate a hash, enter a password in the input field and select a cost factor. The tool defaults to a cost of 10, which provides a good balance between security and performance for most applications. As you type, the bcryptjs library computes the hash in real time, displaying the complete hash string that you can copy and store in your database. The hash includes the embedded salt, so no separate salt storage is required.
To verify a password, paste an existing bcrypt hash into the verifier and enter the password to check. The tool extracts the cost factor and salt from the hash, runs the bcrypt algorithm with the submitted password, and compares the result. A match confirms that the password is correct; a mismatch means the password does not correspond to the hash. This is exactly the same process your application server performs during user login.
- Client-side processing with bcryptjs library
- Generate hashes with configurable cost factors
- Verify passwords against existing bcrypt hashes
- Real-time computation as you type
- No data transmitted to servers
Choosing the Right Cost Factor
The cost factor is the single most important configuration parameter when using bcrypt. It directly controls how long hashing takes, which in turn determines how resistant your hashes are to brute-force attacks. Setting it too low makes attacks feasible; setting it too high creates a poor user experience and risks denial of service.
As a general rule, choose the highest cost factor that your hardware can support while keeping hashing time under an acceptable threshold. For interactive user logins, 250 to 500 milliseconds is a reasonable target. A cost factor of 10 typically takes 50-100ms on modern hardware, while 12 takes 200-400ms, and 13 takes 400-800ms. The right value depends on your server CPU and your tolerance for login latency.
Over time, you should increase the cost factor as hardware becomes faster. When a user with an older hash successfully logs in, you can re-hash their password with the updated cost and store the new hash. This transparent upgrade path ensures that your password security improves continuously without requiring users to reset their passwords.
Be cautious with very high cost factors in production. A cost of 15 or higher may take several seconds per hash, which can be exploited for denial of service. An attacker who knows a valid username can submit login requests to consume excessive server CPU. Implement rate limiting and CAPTCHA to mitigate this risk, regardless of your cost factor.
- Target 250-500ms hashing time for interactive logins
- Cost of 10-12 is typical for modern server hardware
- Increase cost over time and upgrade old hashes on login
- Very high costs risk denial of service without rate limiting
- Measure on production hardware, not just development machines
Bcrypt vs Other Password Hashing Algorithms
While bcrypt is widely recommended, it is not the only password hashing algorithm available. Understanding how it compares to alternatives helps you make informed decisions for your specific requirements.
Scrypt, designed by Colin Percival in 2009, was created specifically to resist hardware attacks by being memory-hard. While bcrypt is CPU-bound, scrypt requires large amounts of RAM, making it expensive to implement on GPUs and ASICs. Scrypt is a good choice when you want memory hardness, though its memory requirements can be challenging in memory-constrained environments.
Argon2 won the Password Hashing Competition in 2015 and is now the recommended algorithm by the OWASP foundation. Argon2 has three variants: Argon2d (resistant to GPU cracking), Argon2i (resistant to side-channel attacks), and Argon2id (a hybrid recommended for most uses). Argon2 is more configurable than bcrypt, allowing independent tuning of time cost, memory cost, and parallelism. If you are starting a new project and your platform supports Argon2id, it is the preferred choice.
PBKDF2 (Password-Based Key Derivation Function 2) is an older NIST-recommended algorithm that applies a pseudorandom function such as HMAC-SHA-256 repeatedly. While still secure when configured with a high iteration count, PBKDF2 is not memory-hard and is more vulnerable to GPU acceleration than bcrypt, scrypt, or Argon2. Use PBKDF2 only when compliance requirements specifically demand it.
- Bcrypt: proven, widely supported, CPU-bound, good default choice
- Scrypt: memory-hard, resistant to GPU attacks
- Argon2id: modern winner of Password Hashing Competition, most recommended
- PBKDF2: NIST-approved but not memory-hard, use only for compliance
- All are vastly superior to fast hashes like SHA-256 for passwords
Best Practices for Password Hashing
Hashing passwords with bcrypt is necessary but not sufficient for a complete password security strategy. A holistic approach combines strong hashing with secure storage, transport, and operational practices.
Always hash passwords on the server, never on the client. Client-side hashing might seem like a good idea to protect the password in transit, but it creates a new vulnerability: the hashed value becomes the effective password. An attacker who intercepts the client-side hash can send it directly to the server without knowing the original password. Rely on HTTPS to protect passwords in transit and perform hashing on the server.
Use a unique salt for every password. Bcrypt handles this automatically, but if you ever use a different algorithm, never reuse salts. Unique salts prevent attackers from precomputing tables and from identifying users who share the same password.
Implement account lockout and rate limiting to slow down online brute-force attacks. Even with strong hashing, an attacker can attempt common passwords against known usernames. Limit the number of failed login attempts per IP address or account, and require CAPTCHA after repeated failures. Consider implementing multi-factor authentication to add a layer of protection that password hashing alone cannot provide.
Monitor for breached passwords using services like Have I Been Pwned. When a user creates or changes a password, check it against known breach databases and reject compromised passwords. When a breach occurs in your own system, force password resets and notify affected users promptly.
- Hash passwords on the server, never on the client
- Always use unique salts per password
- Implement rate limiting and account lockout
- Enable multi-factor authentication
- Check passwords against breach databases
- Force resets and notify users after a security incident