Why bcrypt is deliberately slow

A fast hash function like SHA-256 is a liability, not a feature, when hashing passwords — its speed is exactly what lets an attacker with a stolen hash try billions of password guesses per second on modern hardware. bcrypt is built around the opposite goal: its cost factor directly controls how many internal key-schedule iterations run (2^cost), making each individual hash computation deliberately expensive — a fraction of a second for a legitimate login check, but that same fraction of a second multiplied by billions of guesses becomes computationally infeasible for an attacker. That tunable slowness, not any particular cryptographic novelty, is bcrypt's actual defining feature and the entire reason it remains a recommended choice for password storage decades after its introduction.

What's actually inside a bcrypt hash string

A string like `$2b$10$N9qo8uLOickgx2ZMRZoMye...` is self-describing by design: `$2b$` identifies the algorithm variant, `10` is the cost factor used to generate it, and the rest combines a 22-character salt with the 31-character hash output itself — both salt and hash use bcrypt's own custom Base64-like alphabet, not standard Base64. Because the salt and cost are embedded directly in the stored string, verifying a password later requires no separate lookup of "what salt/cost was used for this user" — everything needed to re-run the same computation and compare is self-contained in the hash string, which is why bcrypt hashes are so straightforward to verify against later even years after the original hash was generated.

The 72-byte limit is real, and shared by every implementation

bcrypt's underlying Blowfish-based key schedule has a hard structural limit of 72 bytes of input — anything beyond the 72nd byte is silently ignored, in this implementation and in every other standards-compliant bcrypt library, not as a quirk of this particular tool. In practice this rarely matters, since a 72-character password already vastly exceeds what anyone types or even a password manager typically generates, but it is worth knowing about if working with unusually long passphrases: two passwords that are identical for their first 72 bytes but differ afterward will produce the exact same bcrypt hash, which is the one genuine edge case this length limit creates.