bcrypt

Why it matters

A fast hash (plain SHA-256, MD5) is the wrong tool for passwords — a GPU rig tries tens of billions of guesses a second against a fast hash, but only tens of thousands against bcrypt, because bcrypt is deliberately tunable to cost more CPU time per attempt (the "work factor" or "cost" parameter). This is the single most common password-storage mistake worth knowing how to spot: a site storing SHA-256(password) instead of bcrypt(password) has effectively no protection once the hash list leaks, and the leak will be run against every other site the users share passwords with.

It is also a compliance item: PCI DSS requirement 8.3.2 requires passwords to be rendered unreadable with strong cryptography, and every modern guideline (NIST SP 800-63B, OWASP) names a deliberately slow, salted algorithm.

How it works, briefly

Each bcrypt hash embeds its own salt and cost factor in the output string, so verification needs no separate lookup — the hash is self-describing:

$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW
 │   │  │                     │
 │   │  └ 22-char salt        └ 31-char hash
 │   └ cost 12 → 2^12 = 4,096 rounds
 └ algorithm version

Raising the cost by one doubles the computation time; the usual target is 250–500 ms per hash on your login servers, which lands around cost 10–12 today and gets bumped as hardware improves — an old hash keeps working (its cost is in the string) and can be re-hashed at the user's next login. Two limits to know: bcrypt only uses the first 72 bytes of the password (pre-hash or cap the length — and know that this once let a long-password bug hide a NUL truncation), and the $2a$ / $2b$ / $2y$ prefixes are implementation variants, all verifiable by a current library.

Argon2id (the 2015 Password Hashing Competition winner) is the current first choice for new systems because it is also memory-hard, which blunts GPU and ASIC attacks; scrypt is the older memory-hard option; PBKDF2 is acceptable where FIPS compliance forces it, with a very high iteration count. bcrypt remains perfectly sound — the sin is not "bcrypt instead of Argon2", it is "SHA-256 instead of either".

Common misreadings

• bcrypt is not encryption. Nobody, including you, can recover the password from the hash; "we encrypt passwords" is either a misstatement or a real problem.
• Salting is not enough by itself. A salted SHA-256 stops rainbow tables but not brute force; the slowness is the protection.
• Peppering is a separate layer. A server-side secret mixed in before hashing (kept out of the database) protects against a database-only leak; it complements bcrypt, it does not replace it.

Related terms

• Salt — A salt is random data mixed into a value before it is hashed, so two identical inputs (two users with the same password) produce different hashes — which defeats precomputed "rainbow table" lookups; bcrypt and Argon2 generate and store it inside the hash automatically.
• Hash Function — A cryptographic hash function turns any input into a fixed-length digest such that the same input always gives the same output, a tiny change gives a completely different output, and — for a secure one — you cannot work back from the digest to the input or find two inputs that share it.
• PCI DSS — PCI DSS is the contractual security standard, set by the card brands through the PCI Security Standards Council, that anyone storing, processing or transmitting payment-card data must meet — currently version 4.0.1.