Bcrypt Hash Explainer - Understand Bcrypt

BCrypt Hash Input

Samples:

Full Hash Anatomy

Version	Algorithm	UTF-8 Safe	Status	Notes
$2$	Original bcrypt	No	Legacy	Original Niels Provos / David Mazières (1999)
$2a$	bcrypt v2a	Partial	Common	Attempted UTF-8 fix; has 8-bit char handling bug on some C implementations
$2x$	bcrypt v2x	No	Broken	Marks hashes produced by the buggy crypt_blowfish <1.0.4 implementation
$2y$	bcrypt v2y	Yes	Good	PHP's crypt() fix — explicitly correct UTF-8 handling
$2b$	bcrypt v2b	Yes	Recommended	OpenBSD canonical — recommended for all new implementations

How BCrypt Works — Step by Step

Password Preprocessing

The password is null-terminated and truncated to 72 bytes (a hard BCrypt limitation). This means passwords longer than 72 bytes hash identically — a known gotcha. The password is encoded as UTF-8 before processing.

password_bytes = utf8_encode(password)[0:72] + '\0'

Generate Random Salt

128 bits (16 bytes) of cryptographically random data are generated. This ensures that two identical passwords always produce different hashes, defeating rainbow table attacks. The salt is encoded in BCrypt's custom Base64 alphabet (22 characters).

salt = crypto_random_bytes(16) // 128 bits salt_b64 = bcrypt_base64_encode(salt) // 22 chars

EksBlowfishSetup — Key Schedule

BCrypt uses the Blowfish cipher's key schedule with an "Expensive Key Setup" (Eks) extension. The initial P-array and S-boxes are seeded with the digits of π (pi), then mixed with the password and salt through 2 ^cost iterations. This is the computationally expensive step.

state = InitState() // π-seeded P-array + S-boxes state = EksBlowfishSetup(state, cost, salt, password) // Internally: 2^cost rounds of: // ExpandKey(state, salt) // ExpandKey(state, password)

Encrypt the Magic String

The ASCII string


          "OrpheanBeholderScryDoubt"

(192 bits, 3 × 64-bit Blowfish blocks) is encrypted 64 times using the derived Blowfish key state. This produces the 24-byte raw digest.

ctext = "OrpheanBeholderScryDoubt" // 24 bytes for i in range(64): ctext = blowfish_ecb_encrypt(state, ctext) // Result: 24 bytes = 192 bits

Encode Output

The first 23 bytes of the 24-byte result are encoded in BCrypt's custom Base64 (31 characters). The last byte is discarded. The final hash is assembled from: version prefix + cost + encoded salt (22 chars) + encoded digest (31 chars) = 60 chars total.

digest_b64 = bcrypt_base64_encode(ctext[0:23]) // 31 chars hash = "$2b$" + zero_pad(cost, 2) + "$" + salt_b64 + digest_b64 // Total: 60 characters

Verification

To verify a password, extract the salt from the stored hash, re-run the entire process with the candidate password and same salt, then compare the output to the stored hash using constant-time comparison to prevent timing attacks.

// ✅ Correct approach (constant-time): hash_verify = bcrypt(candidate_password, stored_salt, stored_cost) return constant_time_compare(hash_verify, stored_hash) // ❌ NEVER use string equality — timing attack risk: // return hash_verify === stored_hash

Blowfish Internals

P-Array (18 × 32-bit subkeys)

The Blowfish P-array consists of 18 32-bit subkeys (P1–P18) initialized from the hexadecimal digits of π. During key setup, they are XOR'd with the password bytes (cycling). Each iteration of EksBlowfish re-runs this mixing.

S-Boxes (4 × 256 × 32-bit entries)

Four substitution boxes each contain 256 32-bit entries, also seeded from π. The Blowfish F-function uses all four S-boxes in a single round: F(x) = ((S₁[a] + S₂[b]) XOR S₃[c]) + S₄[d]. This makes BCrypt memory-hard — 4KB of S-box data must be accessed per round.

Password Hashing Algorithm Comparison

Algorithm	Memory Hard	GPU Resistant	Salt Built-in	Tunable Cost	Max Password	Output Size	Use Today
BCrypt 🔐	Partial (4KB)	Yes	Yes (128 bit)	Cost 4–31	72 bytes ⚠	60 chars	✅ Yes
Argon2id ⭐	Yes (configurable)	Yes	Yes	m, t, p params	Unlimited	Configurable	✅ Recommended
scrypt	Yes (N, r, p)	Yes	Yes	N, r, p	Unlimited	Configurable	✅ Yes
PBKDF2	No	No (GPU-fast)	Yes	Iterations	Unlimited	Configurable	⚠ FIPS required
MD5crypt	No	No	Yes	Fixed (1000)	Unlimited	34 chars	❌ Avoid
SHA-256 (plain)	No	No (billions/sec)	No (manual)	No	Unlimited	64 hex chars	❌ Never for passwords
MD5 (plain)	No	No (50B+/sec)	No	No	Unlimited	32 hex chars	❌ Broken

Recommendation (2026): Use Argon2id for new projects (winner of PHC). Use BCrypt (cost ≥12) for systems where Argon2 is unavailable. Avoid PBKDF2 unless FIPS compliance is required. Never use plain SHA/MD5 for passwords.

BCrypt Quick Reference

Hash Format

A BCrypt hash is always exactly 60 characters : 4-char prefix ( $2b$ ), 2-digit cost, $ separator, 22-char Base64 salt, 31-char Base64 digest. No separators between salt and digest — the split is positional at character 29 from the cost $ .

72-Byte Limit

BCrypt silently truncates passwords to 72 bytes. "password123456…" (73+ chars) hashes identically to the first 72 chars. Mitigation: pre-hash with SHA-256/512 before BCrypt, or use Argon2/scrypt. Some libraries (like bcryptjs) warn about this.

BCrypt Base64

BCrypt uses a custom Base64 alphabet: ./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 — not the standard RFC 4648 alphabet. The output is not decodable with standard atob() or standard Base64 libraries without remapping.

Why Not SHA-256?

SHA-256 runs at billions of hashes per second on modern GPUs (A100: ~100 GH/s). A BCrypt cost 12 hash takes ~250ms — roughly 25 billion times slower. An attacker cracking SHA-256 in 1 second would need 25 billion seconds (>790 years) with BCrypt cost 12.

Bcrypt vs. The Alternatives — Choosing a Password Hashing Algorithm in 2024

Bcrypt is 26 years old and still widely recommended. Here's how it compares to the algorithms that came after it and when you should consider switching.

Algorithm	Year	Memory hardness	Max password length	Current recommendation
bcrypt	1999	No	72 bytes (silently truncates)	Still solid for most web apps — wide library support, 25 years of audits, default in many frameworks
scrypt	2009	Yes	Unlimited	Good — memory-hard defeats GPU attacks better; used by some Linux distros for `/etc/shadow`
Argon2i	2015 (PHC winner)	Yes	Unlimited	Best for password hashing — side-channel-resistant variant; OWASP #1 recommendation since 2019
Argon2id	2015 (PHC winner)	Yes	Unlimited	Best overall — hybrid of Argon2i and Argon2d; OWASP primary recommendation for new systems
PBKDF2-SHA256	2000	No	Unlimited	Acceptable — FIPS-approved; required in US government contexts; needs 600,000+ iterations in 2024
MD5 / SHA-256 (bare)	—	No	Unlimited	Never — nanosecond hashes, billions per second on GPU, no protection at all

Things That Catch Developers Out With Bcrypt

Bcrypt is easy to get mostly right, and those last few percent matter.

72-byte truncation is silent and dangerous

Bcrypt hashes only the first 72 bytes of the input. A password of 73 bytes and a password of 72 bytes that share the same first 72 bytes hash identically. This means someone whose password is 100 characters long effectively has a 72-character password — without being told. Mitigate by pre-hashing: bcrypt(base64(sha256(password))) before passing to bcrypt. This converts an arbitrarily long password into a fixed-length, full-entropy input.

Cost factor 10 isn't enough anymore

Bcrypt was designed in 1999 for hardware that was 10,000× slower. Cost factor 10 meant ~100ms per hash then. On a modern server, cost 10 takes ~10ms. OWASP currently recommends cost 12 as a minimum, targeting 250ms+ per hash on your production hardware. Run a benchmark on your own server and pick the cost factor that keeps login at 250–500ms. Bump it every few years as hardware improves.

bcrypt output is the salt + hash combined

Unlike SHA-256 where you store the salt separately, bcrypt embeds a random 128-bit salt directly in the 60-character hash string: $2b$12$[22-char salt][31-char digest]. This means you only store one string per user, not a hash + salt pair. The verification function parses the embedded salt automatically. Never strip or separate the parts — the whole string is the stored credential.

$2a vs $2b vs $2y — which version prefix?

$2a$ had a bug in some implementations (incorrect handling of 8-bit chars). $2b$ (2011) is the corrected standard. $2y$ is PHP's equivalent of $2b$ . For new code, always use a library that generates $2b$ . Libraries that still generate $2a$ are outdated. All modern bcrypt implementations can verify hashes with any prefix.

Don't bcrypt the same password twice

Some developers pre-hash with SHA-256 and then also apply bcrypt — which is fine if done correctly. But re-running bcrypt on an already-bcrypt-hashed value (e.g., when updating cost factor) produces a double-bcrypt hash that's extremely difficult to manage. To update cost factors for existing users, re-hash only on their next successful login when you have the original password.

Pepper adds defence in depth — but use it carefully

A "pepper" is a site-wide secret mixed into password hashes (separate from the per-user salt). If an attacker steals your database, the pepper stored in application config means they can't crack hashes without also stealing the config. Implement it as a pre-hash step: HMAC-SHA256(pepper, password) before bcrypt. Store the pepper version number alongside the hash so you can rotate it without invalidating all hashes.

Related Tools

Other free security and hashing tools on IndexCraft.

Questions About Bcrypt

Bcrypt is built on the Blowfish cipher's expensive key schedule (EksBlowfish). The algorithm is specifically designed as a one-way function — given a bcrypt hash, there is no mathematical shortcut to the original password. The only practical attack is trial and error: guess a password, bcrypt it with the same salt and cost factor, compare. The deliberate slowness (250–500ms per attempt) makes this computationally expensive even on specialised hardware.

Yes, every time. Bcrypt generates a new cryptographically random 128-bit salt on each hash operation. Two bcrypt hashes of "password123" will look completely different from each other. This is intentional — it means an attacker can't pre-compute a rainbow table. To verify a password, you don't compare hash strings directly; you re-run bcrypt with the salt extracted from the stored hash and see if the outputs match. Every bcrypt library's verify() function handles this automatically.

Existing hashes remain valid at their original cost factor — the cost factor is embedded in the hash string and verified accordingly. Hashes generated before the update will continue to work. To migrate existing users to the higher cost factor, re-hash their password on their next successful login: verify with the old hash, then store a new hash with the updated cost factor. Over time, all active users' hashes will be upgraded. You can query for hashes with the old cost factor to see how many remain.

Less so than SHA-based algorithms, but not immune. Bcrypt's internal state requires significant memory bandwidth and is not easily parallelised on GPU architectures in the same way SHA is. Modern GPUs can still run millions of bcrypt attempts per second at cost 10, but that's orders of magnitude fewer than the billions they achieve with SHA-256. This is why cost factor escalation and memory-hard alternatives (Argon2id) continue to matter — Argon2id's configurable memory requirement makes GPU parallelism expensive in a way bcrypt doesn't.

For a running system: opportunistically, not all at once. Argon2id (especially with high memory settings) provides better protection against GPU and ASIC cracking than bcrypt, and is the OWASP primary recommendation for new systems. However, bcrypt at cost 12+ remains acceptable — you're not in urgent danger if you're using bcrypt correctly. The migration path is the same as cost-factor upgrades: detect the algorithm from the hash prefix, verify with the old algorithm on login, re-store with Argon2id. Plan for it on your next major auth refactor rather than as an emergency.