Password Hashing with Bcrypt: Work Factors, Salt, and Security Specs

Storing raw, plaintext passwords in databases is a catastrophic security violation. Even standard fast cryptographic hashes (like SHA-256 or MD5) are vulnerable to hardware-accelerated GPU cracking tables.

Bcrypt (designed by Niels Provos and David Mazières in 1999 based on the Blowfish cipher) remains an industry-standard password hashing algorithm due to its **adaptive cost factor**.

1. Why Fast Hashes (MD5/SHA-256) Fail for Passwords

Fast hash functions are designed for high throughput (e.g., verifying network packet integrity). Modern GPU clusters can calculate over **100 billion SHA-256 hashes per second**.

If a database containing SHA-256 password hashes is compromised, attackers can use pre-computed **rainbow tables** or brute-force combinations to crack weak and medium-strength user passwords in seconds.

2. How Bcrypt Solves Password Cracking

Bcrypt incorporates two fundamental defensive mechanisms:

Mechanism 1: Cryptographic Salt

Before hashing, Bcrypt generates a random 128-bit (16-byte) salt. The salt is prepended to the password before hashing and stored alongside the final hash output string.

**Security Benefit:** Salt ensures that two users with identical passwords (e.g., "Password123!") produce completely different hash outputs. This renders pre-computed rainbow tables completely ineffective.

Mechanism 2: Adaptive Cost Factor (Work Factor)

Bcrypt uses key stretching to deliberately slow down calculation speed. The cost parameter specifies 2^cost iterations of the internal Blowfish expansion loop.

code

Cost 10 = 2^10 = 1,024 iterations
Cost 12 = 2^12 = 4,096 iterations (~250ms parse time)
Cost 14 = 2^14 = 16,384 iterations (~1.2s parse time)

3. Deconstructing a Bcrypt Hash String

A generated Bcrypt hash output looks like this:

code

$2a$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquii.FF79U2S6.nUp2XvG
│  │  │                     │
│  │  │                     └─ 184-bit Encrypted Password Hash (31 chars)
│  │  └─────────────────────── 128-bit Salt (22 chars)
│  └────────────────────────── Cost Factor (12 = 4096 rounds)
└───────────────────────────── Algorithm Version Identifier ($2a$, $2b$, or $2y$)

4. 2026 Industry Recommendations

**Minimum Cost Factor:** Use a cost factor of **12** for web applications. This balances server CPU load (~250ms verification time per sign-in request) while rendering hardware brute-force attacks economically infeasible for attackers.

**Max Password Length Caveat:** Standard Bcrypt truncates passwords longer than **72 bytes**. To handle arbitrarily long user passwords without truncation, pre-hash long input passwords using SHA-256 before passing them to the Bcrypt hashing pipeline.

Generate & Verify Bcrypt Hashes Securely

Need to generate test Bcrypt hashes or check whether a hash matches a password? Test parameters safely in your browser using our client-side [Bcrypt Generator](/security/bcrypt-generator) and [Bcrypt Verifier](/security/bcrypt-verifier).

Try the Interactive Tool