About the Bcrypt Hash Generator
The Bcrypt Hash Generator produces bcrypt password hashes and verifies passwords against existing bcrypt hashes. Bcrypt is an adaptive password hashing algorithm designed by Niels Provos and David Mazières in 1999 — it remains one of the most widely used and trusted algorithms for secure password storage in web applications.
How to Use
- Enter the password to hash in the input field.
- Set the cost factor (also called work factor or rounds). Values between 10 and 14 are recommended for most applications.
- Click Generate Hash. A new random salt is generated automatically and embedded in the output hash string.
- To verify a password against an existing hash, paste the bcrypt hash and the password to test, then click Verify.
How Bcrypt Works
Bcrypt is built on the Blowfish cipher and is deliberately slow by design:
- Salt generation — A 128-bit random salt is generated per hash. The salt prevents precomputed rainbow table attacks and ensures two identical passwords produce different hashes.
- Key expansion — The Blowfish key schedule is run 2cost times. At cost 10, this is 1,024 iterations; at cost 12, it is 4,096. The exponential scaling means each additional cost unit doubles the computation time.
- Hash output — The output is a 60-character string in the Modular Crypt Format:
$2y$[cost]$[22-char salt][31-char hash].
- Self-contained format — The full hash string contains the algorithm identifier, cost factor, salt, and hash — everything needed for verification. Store the complete string; do not separate the components.
Bcrypt Hash Format
A bcrypt hash looks like: $2y$12$LrmaXSnAzShXFJaVwHrXsebcG.MFJkBUf5wXRKG4EHwplL69L6ZMm
$2y$ — Algorithm identifier. $2y$ is the current PHP version; $2b$ is the canonical bcrypt format (used by most other languages); $2a$ is an older variant with a known bug for passwords with certain 8-bit characters.
12 — The cost factor. This hash used 212 = 4,096 iterations of the key schedule.
- The remaining 53 characters are a Base64-encoded combination of the 22-character salt and 31-character hash output.
Choosing the Right Cost Factor
- Cost 10 — Approximately 100 ms per hash on a modern server. Minimum recommended for new applications.
- Cost 12 — Approximately 400 ms per hash. Recommended for applications with lower login frequency or higher security requirements. The Laravel default.
- Cost 13–14 — 800 ms to 1.6 seconds per hash. Appropriate for high-value accounts, admin panels, or financial applications.
- Adaptive scaling — Bcrypt's cost factor can be increased as hardware improves. Existing hashes remain valid; new hashes use the higher cost. Rehash on login when you increase the cost factor.
- Benchmark first — Run
password_hash('test', PASSWORD_BCRYPT, ['cost' => 12]) timed on your production hardware. Target 200–400 ms for interactive logins.
Bcrypt vs Argon2 vs PBKDF2
- Bcrypt — Widely supported, battle-tested since 1999. Memory cost is fixed and low (~4 KB), which limits resistance to GPU attacks as hardware improves. Maximum password length is 72 bytes — passwords longer than 72 bytes are silently truncated.
- Argon2id — The modern recommendation. Configurable memory cost makes GPU attacks expensive. No 72-byte truncation. Choose Argon2id for new applications where it is available.
- PBKDF2 — No memory hardness, can be GPU-parallelised. Required for FIPS compliance. Use only when bcrypt and Argon2 are unavailable.
- MD5 / SHA-1 (unsalted) — Not password hashing algorithms. Fast by design and trivially brute-forced. Never use for password storage.
Frequently Asked Questions
- Why does bcrypt truncate passwords at 72 bytes?
- Bcrypt is based on the Blowfish cipher, which uses a key setup routine with a 72-byte (576-bit) limit. Characters beyond 72 bytes are silently ignored. A password of "correcthorsebatterystaple..." and a password of "correcthorsebatterystaple...XYZ" may hash identically if the difference falls after byte 72. To avoid this, some implementations pre-hash the password with SHA-256 before bcrypt — a common pattern but check your framework's documentation for its specific approach.
- How do I implement bcrypt in PHP?
password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]) generates the hash. password_verify($password, $hash) verifies it. password_needs_rehash($hash, PASSWORD_BCRYPT, ['cost' => 12]) detects when to rehash (e.g., after increasing the cost factor). These functions are in PHP core — no library needed.
- How do I implement bcrypt in Node.js?
- The
bcrypt package (npm install bcrypt) or the pure-JavaScript bcryptjs package are the standard options. Use bcrypt.hash(password, 12) to hash and bcrypt.compare(password, hash) to verify. The bcrypt package uses native bindings for better performance; bcryptjs is a drop-in replacement with no native dependency.
- Can bcrypt hashes be cracked?
- Not feasibly with a properly chosen cost factor and a strong, unique password. At cost 12, a high-end GPU cluster can test roughly 100–1,000 bcrypt hashes per second (compared to billions for MD5 per second). A 12+ character random password is effectively uncrackable. Short or common passwords (dictionary words, names, dates) remain vulnerable regardless of the algorithm — bcrypt buys time, not immunity from weak passwords.
- Why does verifying a bcrypt hash take the same time as hashing?
- By design. The cost factor embedded in the hash tells the verifier how many iterations to run. This ensures that offline brute-force attacks against a stolen hash database are just as slow as the original hashing — making large-scale password cracking computationally prohibitive.