bcrypt is a password hashing function designed in 1999 by Niels Provos and David Mazières for OpenBSD. Unlike general-purpose hash functions (MD5, SHA-256) that are optimized for speed, bcrypt is deliberately slow — a design choice that makes brute-force attacks against stolen password databases painful.
Hash Format
$2b$12$Rn8OqhElVXYs.7g5CD3Ovu8k5UyC.pQxPnr4jZTvC9NcJC/1kHJbG$2b$— bcrypt version identifier12— work factor (cost — 2^12 = 4096 iterations of the internal loop)- next 22 chars — salt (base64-encoded, 128 bits of entropy)
- last 31 chars — the hash
Adaptive Cost
The work factor is stored in the hash. As hardware gets faster, you increase the cost when hashing new passwords. Old hashes remain verifiable at their original cost. Rehash on user login when cost is out of date.
Modern Recommendation
Work factor 12 in 2026 is the practical baseline (~250ms per hash on a modern server). Bump to 13 if your infra can absorb the CPU. Higher costs are fine but you’re paying to make login slower.
bcrypt vs Argon2
Both are correct choices for password hashing. Argon2 is newer (2015) and won the Password Hashing Competition; bcrypt is battle-tested since 1999. Either will do — pick what your framework supports natively.
Common Miss
Wrapping bcrypt with an outer SHA-256 (bcrypt(sha256(password))). Doesn’t add security, but caps the password’s effective entropy at 256 bits — irrelevant here — and complicates the code path.
Generate bcrypt hashes with the hash generator.
Related
Check the Argon2 glossary entry, the SHA-256 entry, and the MD5 entry — the wrong choice for passwords.