Bcrypt was introduced in 1999 by Niels Provos and David Mazières at USENIX, built around Bruce Schneier's Blowfish cipher from 1993. Instead of inventing a new primitive, they exploited a quirk of Blowfish: its key-setup phase is unusually slow, because it recomputes internal lookup tables many times before a single byte gets encrypted. Provos and Mazières repurposed that "slow key schedule" as the entire point of the algorithm — decades before "memory-hard" or "deliberately slow" became standard vocabulary in password hashing.
Why speed hurts password security
If an attacker steals a database of password hashes, they try to recover the original passwords by brute force. With a fast function like SHA-256, modern hardware checks billions of guesses per second. If hashing a single password deliberately takes 100 milliseconds instead, brute-forcing becomes orders of magnitude slower and more expensive — which is precisely what Blowfish's slow key setup was repurposed to guarantee.
What the cost factor is
Bcrypt's "cost" parameter sets the number of key-setup rounds as a power of two (2^cost, typically 10-12). Raising it by one roughly doubles the time per hash — and doubles the attacker's total brute-force bill. Unlike a fixed algorithm, this lets bcrypt stay relevant as hardware gets faster: administrators just increase the cost over the years.
Built-in salt
Bcrypt automatically generates a unique random salt for each password and embeds it directly in the output — there's nothing separate to store. Two identical passwords produce different hashes, and precomputed rainbow tables for common passwords become useless: every hash has to be attacked individually.
Why you'd need this
- Storing user passwords correctly in an application's database.
- Understanding why SHA-256 or MD5 is a poor choice for password hashing.
- Testing or migrating an authentication system that uses bcrypt.
A hidden limit: 72 bytes
Because it's built on Blowfish's 448-bit key schedule, bcrypt only ever processes the first 72 bytes of a password — anything beyond that is silently dropped, a direct consequence of the cipher it's built from rather than an arbitrary choice. In practice this rarely matters for English-language passwords (72 ASCII characters is already extremely long), but it's worth knowing when validating maximum password length in a signup form.