What is bcrypt?

Why bcrypt still matters

Password databases leak often enough that stored passwords must be designed for breach conditions. bcrypt helps by making each password guess intentionally expensive and by embedding a unique salt into every stored hash string.

It is not the newest password-hashing option, but it remains widely deployed, well studied, and supported across major languages. The important engineering question is not whether bcrypt is fashionable; it is whether the cost factor, input handling, and migration plan match today's threat model.

What bcrypt stores in a password hash

A bcrypt hash is more than a digest. The encoded string carries the algorithm version, cost factor, salt, and derived output so verification can repeat the same work without a separate parameter database.

How bcrypt password verification works

Cost factor, 72-byte limit, and algorithm choice

bcrypt's cost is logarithmic: raising the factor by one roughly doubles the work. That makes tuning simple, but it also means a setting that felt strong several hardware generations ago can become weak without periodic benchmarking.

The other common surprise is bcrypt's 72-byte input limit. Many implementations ignore bytes after that boundary, and multi-byte Unicode characters can make "72 characters" and "72 bytes" very different. Avoid homegrown fixes; if you pre-hash long passwords before bcrypt, use a vetted pattern that preserves entropy, handles encoding consistently, and does not introduce a fast unsalted verifier.

Operational checklist

Good bcrypt deployments pair cryptographic settings with authentication controls and a migration path.

• Use a maintained bcrypt library that stores and verifies the full encoded hash string.
• Benchmark the cost factor on production-like hardware and choose the highest value that preserves acceptable login latency.
• Generate a unique random salt for every password; let the library encode it with the hash.
• Document how your stack handles passwords longer than 72 bytes, especially after Unicode normalization or UTF-8 encoding.
• Rehash on successful login when stored hashes use an outdated cost or bcrypt prefix.
• Combine bcrypt with rate limiting, MFA, breached-password screening, and monitoring for credential stuffing.
• Keep any pepper outside the password database, preferably in a secrets manager or HSM, with a rotation plan.
• Do not log plaintext passwords, bcrypt inputs, salts paired with debugging traces, or full password hash dumps.

bcrypt versus Argon2 for new systems

bcrypt is durable because it is simple to deploy and hard to misuse when a mature library owns the format. Its weakness is that it mainly consumes CPU time, so attackers with dense GPU or ASIC rigs can still parallelize large cracking campaigns more efficiently than they can against a well-tuned memory-hard function.

For new applications, Argon2id usually gives a stronger default path. For existing bcrypt systems, a careful migration often beats a rushed rewrite: raise weak costs first, add rehash-on-login, and move users to Argon2id only after the authentication service can validate both formats safely.

The practical takeaway

bcrypt remains a credible password-hashing function when its cost factor is current, salts are unique, and long-password behavior is understood. It should never stand alone: rate limiting, MFA, secure password reset flows, and breach monitoring all matter because password hashing mainly protects the offline-cracking scenario after a verifier database is stolen.

If you are starting fresh, choose Argon2id unless platform constraints make bcrypt the safer operational choice. If you already run bcrypt, keep it tuned, measure it regularly, and plan upgrades before hardware trends make yesterday's cost factor too cheap.