About

Bcrypt hashes encode four discrete fields into a single 60-character string: the algorithm version (v), the cost factor (c), a 128-bit salt, and a 184-bit digest. Misidentifying the cost factor or confusing 2a with 2b can cause authentication failures during system migrations. A cost factor of 10 produces 1,024 iterations; each increment doubles computation time, so choosing the wrong value either exposes passwords to brute-force attack or cripples server throughput.

This tool parses a bcrypt hash string, validates its structural integrity against the specification, and extracts every component for inspection. It estimates brute-force resistance based on published GPU benchmarks. Note: the tool cannot reverse the hash. It approximates cracking time assuming a single high-end GPU at roughly 50,000 hashes per second at cost 5. Real-world times vary with hardware parallelism and password entropy.

Formulas

A valid bcrypt hash follows this fixed-length structure of 60 characters:

$2b$12$salt(22 chars)hash(31 chars)

The iteration count is derived from the cost factor c:

iterations = 2^c

Estimated brute-force time for a password space of size S on a device computing H hashes per second:

T = S2 ⋅ H

The GPU hash rate at a given cost is modeled as:

H_c = H₅2^{(c − 5)}

where H₅ ≈ 50,000 h/s is the baseline rate at cost 5 on a modern GPU. c is the cost factor extracted from the hash. S is the password search space size. T is the expected time to exhaust half the space (median crack time).

Reference Data

Version	Identifier	Year	Notes
Original	$2$	1999	Initial OpenBSD implementation. No handling of non-ASCII or null bytes.
Revised (a)	$2a$	2004	Added null terminator and UTF-8 handling. Dominant in most libraries.
Fixed (b)	$2b$	2014	OpenBSD fix for wrapping bug with passwords > 255 bytes.
Crypt Blowfish (y)	$2y$	2011	PHP crypt_blowfish fix. Equivalent to correct $2a$ in other languages.
Crypt Blowfish (x)	$2x$	2011	Backward compat for buggy PHP hashes. Should not be generated.

Cost Factor	Iterations (2^c)	Approx. Time / Hash (CPU)	Approx. Time / Hash (GPU)	Security Rating
4	16	< 1 ms	< 0.1 ms	Extremely Weak
6	64	~3 ms	~0.4 ms	Weak
8	256	~12 ms	~1.5 ms	Below Average
10	1,024	~50 ms	~6 ms	Minimum Acceptable
12	4,096	~200 ms	~25 ms	Good (Recommended)
13	8,192	~400 ms	~50 ms	Strong
14	16,384	~800 ms	~100 ms	Very Strong
15	32,768	~1.6 s	~200 ms	Very Strong
16	65,536	~3.2 s	~400 ms	Excellent
18	262,144	~13 s	~1.6 s	Maximum Practical
20	1,048,576	~52 s	~6.5 s	Extreme (DoS risk)
31	2,147,483,648	~17.9 hours	~2.2 hours	Theoretical Maximum

Frequently Asked Questions

Version $2a$ was the first revision that handled UTF-8 and null terminators. OpenBSD discovered a wrapping bug for passwords exceeding 255 bytes and introduced $2b$ as the corrected version in 2014. Version $2y$ is specific to PHP's crypt_blowfish library, introduced to distinguish correctly-computed hashes from those generated by an earlier buggy implementation. In practice, $2a$, $2b$, and $2y$ produce identical output in correctly implemented libraries. The version prefix matters primarily during migration between systems using different libraries.

Bcrypt encodes the salt and digest using the alphabet ./A-Za-z0-9 instead of the RFC 4648 standard A-Za-z0-9+/. This originates from the OpenBSD crypt(3) convention, which predates the base64 RFC. The . and / characters replace + and = to avoid issues with password file parsing and padding. This is why standard base64 decoders cannot directly decode bcrypt components.

OWASP recommends a minimum cost factor of 10, with 12 as the preferred default for most web applications. The goal is a hash computation time between 200 and 500 ms on your production hardware. Above 16, login latency becomes noticeable to users. You should benchmark on your actual server: run 100 hashes at different cost factors and measure the 95th percentile latency. Increase the cost by 1 every 18 months to track Moore's Law.

No. Bcrypt is a one-way key derivation function based on the Eksblowfish cipher. Reversing the hash is computationally infeasible. This tool only performs structural analysis: it extracts the version, cost factor, salt, and digest from the encoded string. The brute-force time estimates are theoretical calculations based on published GPU benchmarks, not actual cracking attempts.

Bcrypt's modified base64 encoding maps 6 bits per character. 22 characters encode 132 bits, but bcrypt truncates the final 4 bits, yielding exactly 128 bits of salt. This means the last character of the salt only contributes 2 meaningful bits. Changing the last character may produce an identical salt depending on which bits differ.

The cost factor exclusively controls the number of rounds in the Eksblowfish key schedule. It has no influence on salt generation. The 128-bit salt is generated independently by a cryptographic random number generator. The key schedule performs 2^c iterations of expensive key setup, alternately encrypting with the salt and the password-derived key.