Bcrypt hashes look random, but the format $2b$12$LJ3m4...3hJlKqS tells you everything. The $2b$ says "I am bcrypt, version b." The 12 says "I cost 2^12 iterations." The next 22 characters are the base64-encoded 128-bit salt. The final 31 characters are the 184-bit derived hash. A human glancing at that string can read it like a label.
This tool hashes a password with a real bcrypt implementation (pure JavaScript, in-browser) and also verifies a plaintext against a stored hash. The comparison is constant-time; it does not leak timing.
The gotcha that breaks the most production systems: the 72-byte bcrypt limit.
Bcrypt uses the Blowfish key schedule, which only accepts a 576-bit key. Passwords longer than 72 bytes are silently truncated. There is no error, no warning, no diagnostic -- p@sswordThatIsWayTooLongForBcrypt1234567890 and p@sswordThatIsWayTooLongForBcrypt hash identically if they share a 72-byte prefix. This becomes a real problem when an SSO system produces authentication assertions longer than 72 bytes and your login flow breaks for engineers but not for everyone else. If you expect to receive long tokens, SHA-256 pre-hashing (with a "do not skip this" comment) is the usual workaround -- but it belongs in your application code, not here.
Cost factor: each increment doubles how long hashing takes. The recommended default bakes in hardware of today, not tomorrow. Tuning advice:
- Cost 4-6 -- development. Fast iteration on local machines. Never in production.
- Cost 10-12 -- current production default. About 100-500 ms per hash on a modern server CPU. OWASP recommends targeting 250-500 ms per hash.
- Cost 13-14 -- sensitive systems (banking, healthcare). Seconds per login.
- Cost 15+ -- high-security contexts. Several seconds. Measured in human patience as much as compute.
Always benchmark on your actual deployment hardware -- a shared CPU in a cheap VPS hashes at a fraction the rate of a rented bare-metal instance.
Bcrypt, then and now:
-
Battle-tested since 1999. Not a single practical attack algorithm that materially weakens well-configured bcrypt has been published. The "weakness" (low RAM, parallelizable on GPU) is well-understood and less concerning than it sounds: GPUs are great at bcrypt until you crank the cost factor.
-
Built-in salt. Every hash gets a fresh 128-bit random salt, baked into the output. No salt management for you to screw up. Two users with the same password get different hashes automatically.
-
Aging gracefully. To re-hash all your users at a higher cost, verify against the old hash on login, then re-hash with the new cost. No forced password reset needed.
Alternatives exist (scrypt, Argon2, PBKDF2) and for new projects Argon2id is the OWASP recommendation. But bcrypt remains the right answer for "I need a password hash function that I cannot accidentally misconfigure." It has the smallest attack surface of any option.