Why password hashing matters and where bcrypt fits
Storing user passwords in plain text is a serious security risk: if your database is exposed, attackers immediately gain full access to accounts. One-way hashing addresses that by converting a password into a fixed-size string that cannot be reversed to reveal the original password. Bcrypt is a widely adopted password hashing function designed specifically for this task. It makes brute-force attacks expensive by design, forces use of unique salts to defeat precomputed tables, and allows teams to tune the computational cost as hardware evolves.
What is bcrypt?
Bcrypt was introduced in 1999 by Niels Provos and David Mazieres as a password hashing function based on the Blowfish cipher. Rather than being a general-purpose hashing primitive, bcrypt is tuned for password storage: it is intentionally slow and includes a configurable “cost” parameter that controls how expensive it is to compute a hash. Each bcrypt output contains the algorithm identifier, the cost factor, the generated salt, and the resulting hash. Because the salt is stored with the hash, a server can verify passwords later without keeping extra secret data.
How bcrypt works , the main steps
At a high level, bcrypt converts a password into a hash using a per-password salt and an adjustable work factor. The process starts with generating a cryptographically secure random salt, then performing a computationally intensive key setup and mixing routine derived from the Blowfish key schedule (often called EksBlowfish). The cost factor determines how many internal rounds are executed; doubling the cost roughly doubles the time required to compute a hash. The final output encodes all the parameters needed for verification.
Step 1 , Unique salt generation
For every password, bcrypt generates a fresh random salt (commonly 16 bytes). Salts ensure that identical passwords produce different hashes and make precomputed rainbow tables ineffective. Since the salt is stored alongside the hash, a server can re-run the same hashing process during login attempts.
Step 2 , Cost (work) factor)
The cost factor,sometimes called the work factor or log rounds,is an integer that controls how expensive the hashing is. A cost of 12 means 2^12 iterations of the internal mixing. Increasing the cost makes each hash slower, which raises the attacker’s cost for brute-force searches and gives defenders a simple knob to respond to faster hardware.
Step 3 , Key setup and mixing
Bcrypt uses an expensive key setup adapted from Blowfish. The algorithm repeatedly mixes the password and salt into the internal state; because of that design, bcrypt imposes CPU work that is harder to parallelize in low-memory settings. The result is a 192-bit value which is then truncated and encoded as the final hash string.
Step 4 , Hash storage and verification
The stored bcrypt string includes the version, cost, salt, and hash, so verification simply recomputes the bcrypt hash with the stored salt and cost and compares the results. Use a constant-time comparison function to avoid leaking timing information during verification.
Why bcrypt improves website security
Bcrypt reduces the usefulness of stolen password databases in several ways. First, unique salts prevent attackers from identifying common passwords or using precomputed hash tables. Second, the adjustable cost means you can increase computational expense as hardware gets faster, keeping attack costs high. Third, bcrypt’s design slows down attackers even on specialized hardware, because its internal structure makes naive parallelization less effective than with simple fast hashes like SHA-256. Taken together, these properties make online and offline cracking attempts far more expensive and time-consuming.
Limitations and comparisons with newer algorithms
Bcrypt is strong for many use cases, but it has limits. It truncates input passwords longer than 72 bytes, which can unexpectedly cut user input if you allow very long passphrases. It is not memory-hard the way Argon2 is, so modern GPUs and ASICs can still accelerate bcrypt attacks more efficiently than strictly CPU-bound hashing would suggest. For maximum future-proofing, consider Argon2 (the winner of the Password Hashing Competition) if you require memory-hard resistance against GPU/ASIC parallelism. However, bcrypt remains broadly supported across languages and libraries and is often a pragmatic choice for many websites.
Best practices when using bcrypt on a website
Using bcrypt correctly matters as much as choosing it. Generate a cryptographically secure unique salt for each password and store the full bcrypt string (which contains salt and cost). Choose a cost factor by benchmarking on production-like hardware: pick the highest cost that keeps user login latency acceptable (commonly 100–500 ms). When server performance improves, increment the cost and re-hash passwords on next login or run a background migration. Pair bcrypt with additional defenses: rate-limit login attempts, monitor for credential stuffing, encourage multi-factor authentication, and never log raw passwords.
- Use secure libraries (e.g., bcrypt libraries for Node, Python, Ruby, php) instead of custom implementations.
- Store the full bcrypt output string; it contains everything needed for verification.
- Benchmark and choose a cost factor appropriate for your hardware and threat model.
- Consider migrating to Argon2 if you need stronger memory-hard resistance.
Common implementations and tools
Bcrypt is available in nearly every modern programming ecosystem. For Node.js, popular packages include bcrypt and bcryptjs. In Python, use the bcrypt package (often via passlib for a higher-level API). PHP offers password_hash and password_verify with PASSWORD_BCRYPT. Ruby developers commonly use the bcrypt gem. Using well-maintained libraries avoids subtle mistakes and handles salt generation, encoding, and safe comparisons for you.
When bcrypt is not the right choice
If you need protection specifically against attackers with high GPU/ASIC resources, choose a memory-hard algorithm such as Argon2. If you must accept extremely long passphrases beyond 72 bytes, bcrypt’s truncation can cause problems; you can pre-hash inputs or use a different algorithm that accepts longer inputs without truncation. Finally, if you require reversible encryption rather than one-way password verification (for example, to recover user data), hashing is the wrong approach,use authenticated encryption with proper key management.
Concise summary
Bcrypt is a battle-tested password hashing function that combines per-password salts and an adjustable cost factor to slow down attackers and protect stored passwords. It remains a practical choice for many websites thanks to wide library support and a tunable work factor, but it has limits,most notably input-length truncation and weaker memory hardness than newer algorithms like Argon2. Implement bcrypt using trusted libraries, choose an appropriate cost through benchmarking, and combine hashing with other security controls such as rate limiting and multi-factor authentication.
FAQs
Is bcrypt better than SHA-256 for storing passwords?
Yes. SHA-256 is a fast cryptographic hash intended for integrity checking, not password storage. Fast hashes allow attackers to try billions of guesses per second. Bcrypt is intentionally slow and includes salts and a configurable cost, making brute-force attacks far more expensive.
How do I choose the right bcrypt cost factor?
Benchmark bcrypt on hardware similar to your production servers and choose the highest cost that keeps login latency acceptable,often around 100–500 milliseconds per hash. Re-evaluate periodically and increase the cost as hardware improves.
Does bcrypt protect against rainbow table attacks?
Yes. Because bcrypt uses a unique per-password salt stored with the hash, precomputed rainbow tables are ineffective. An attacker would need to compute a new table for each salt, which is impractical.
Should I use Argon2 instead of bcrypt?
Consider Argon2 if you need memory-hard resistance against GPU/ASIC attacks or if you’re building for the highest contemporary password security standards. Bcrypt remains a solid, well-supported option for many systems, but Argon2 is generally recommended for new designs where maximum resistance to specialized hardware is a priority.
What happens if I need to increase bcrypt’s cost later?
You can increase the stored cost by re-hashing passwords at the new cost the next time users log in, or run a one-time migration that re-hashes known good passwords. Keep the old hashes until re-hashes complete; the stored bcrypt string indicates the cost used for verification.
