Bcrypt Generator

Input any plain text, it bcrypt encrypted hash

Bcrypt Generator

Input any plain text, it bcrypt encrypted hash

Your bcrypt hash will appear here

Check Bcrypt

Input hash value and plain text, check it right or not

Advertisement
Ad Space

Your Google AdSense ad will appear here

Maximum Security

Bcrypt is specifically designed for password hashing with built-in salt generation and resistance to rainbow table attacks.

Adjustable Rounds

Choose cost factor from 4-16 rounds. Higher rounds increase security but require more computation time.

Instant Generation

Generate secure bcrypt hashes in seconds. Fast, reliable, and easy to integrate into your workflow.

Password Verification

Quickly verify if a plain text password matches an existing bcrypt hash for authentication testing.

The Definitive Guide to Bcrypt & Modern Password Security

Written by RedoHub Editorial Team · Last updated: September 12, 2026
Advertisement

In software engineering and application security, password storage is one of the most critical responsibilities a developer undertakes. A single database breach exposing poorly hashed credentials can compromise user accounts across thousands of web platforms due to password reuse. Bcrypt is the battle-tested, industry-standard adaptive password hashing function engineered specifically to protect credentials against specialized hardware and offline brute-force cracking.

This architectural guide explains why fast cryptographic hashes (like SHA-256 or MD5) are fundamentally unsafe for passwords, dissects the inner workings of Bcrypt's Eksblowfish key schedule, provides latency benchmarks for selecting optimal cost factors, demonstrates production implementations, and solves the well-known 72-byte truncation limitation.

1. The Fast Hash Trap: Why MD5 & SHA-256 Are Fatal for Credentials

A widespread security vulnerability in web applications stems from a basic misunderstanding: assuming that because SHA-256 is cryptographically secure for file integrity, it must be secure for passwords. This assumption is dangerously false.

General-purpose hash algorithms (MD5, SHA-1, SHA-256, SHA-512) were engineered for maximum throughput. Storage controllers, network routers, and digital signature validators require algorithms that can process hundreds of megabytes per second with minimal CPU overhead. However, when applied to human-generated passwords, extreme execution speed empowers the attacker:

Algorithm / Function Category Modern GPU Throughput (Hashcat / RTX 4090) Time to Crack 8-Char Alphanumeric Password
MD5 General-Purpose Hash ~164 Billion hashes / second Under 2 seconds
SHA-256 General-Purpose Hash ~28 Billion hashes / second Under 8 seconds
SHA-512 General-Purpose Hash ~9.5 Billion hashes / second Under 25 seconds
Bcrypt (Cost 10) Key Derivation Function (KDF) ~6,200 hashes / second Several Weeks
Bcrypt (Cost 12) Key Derivation Function (KDF) ~1,550 hashes / second Multiple Years
Why Salts Alone Cannot Fix Fast Hashes:

A cryptographic salt prevents precomputed Rainbow Table attacks by ensuring two identical passwords produce different digests. However, a salt does nothing to slow down modern GPU or ASIC brute-force attacks. When an attacker has access to your leaked database, they compute SHA256(password + salt) at billions of attempts per second. True password security requires computational slowness (Key Stretching).

2. How Bcrypt Works: The Eksblowfish Algorithm

Introduced at USENIX in 1999 by cryptographers Niels Provos and David Mazières for OpenBSD, Bcrypt is founded upon Bruce Schneier's Blowfish symmetric cipher. What distinguishes Bcrypt from standard encryption is its Eksblowfish (Expensive Key Schedule Blowfish) routine:

  • State Initialization: Eksblowfish initializes 4 Kilobytes of internal S-box memory arrays.
  • Iterative Key Expansion: It repeatedly modifies the S-boxes and permutation subkeys in a tight loop executed $2^{\text{cost}}$ times, interleaving the user's password and the random salt.
  • Ciphertext Generation: After the key schedule concludes, the algorithm encrypts the 192-bit fixed string "OrpheanBeholderScryDoubt" 64 times using Electronic Codebook (ECB) mode.
  • Memory-Hardness: Because Blowfish requires frequent, pseudo-random lookups across its internal S-boxes, it cannot easily be parallelized on GPU architectures, which favor linear compute streams over random memory access.
Anatomy of a Modular Crypt Bcrypt Hash:

$2b$12$e8eYQ9F9cKzG7pXbY7eZ3uO2aZ4fB8dC0eE2gG4iI6kK8mM0oO2qS

  • $2b$ → Algorithm revision identifier (the modern, secure standard).
  • 12$ → Cost factor parameter ($2^{12} = 4,096$ key schedule iterations).
  • e8eYQ9F9cKzG7pXbY7eZ3u → 22-character Radix-64 encoded 128-bit cryptographic salt.
  • O2aZ4fB8dC0eE2gG4iI6kK8mM0oO2qS → 31-character Radix-64 encoded 184-bit ciphertext digest.

3. Choosing the Optimal Cost Factor (Work Factor)

The core advantage of Bcrypt is its adaptive cost factor. As computing power increases according to Moore's Law, developers do not need to rewrite their authentication architecture—they simply increment the cost parameter:

  • Cost 10 ($2^{10} = 1,024$ rounds): Takes roughly 80ms to 120ms on modern cloud VPS hardware. Acceptable for microservices with high concurrent login bursts or mobile backends.
  • Cost 12 ($2^{12} = 4,096$ rounds): Recommended Industry Standard for 2026. Takes roughly 250ms to 350ms per password verification. Imperceptible to human users during sign-in, but overwhelmingly expensive for an offline attacker.
  • Cost 14 ($2^{14} = 16,384$ rounds): Takes approximately 1,000ms to 1,500ms. Recommended for high-security financial transactions or master administrative accounts.
Preventing Denial of Service (CPU Exhaustion):

Because bcrypt intentionally consumes CPU cycles, an unauthenticated attacker could flood your login endpoint with thousands of bogus authentication requests, saturating all server CPU cores. Always pair Bcrypt with strict login rate limiting (e.g., maximum 5 attempts per minute per IP address, backed by Redis or an API gateway).

4. The 72-Byte Truncation Limit & The Pre-Hashing Solution

A critical architectural detail often overlooked by software engineers is that Bcrypt silently truncates passwords at 72 bytes. If a user inputs a 90-character passphrase, every character past byte 72 is ignored by the Blowfish key schedule: "password123...[72 bytes]...AAA" produces the exact same hash as "password123...[72 bytes]...ZZZ".

The Architectural Fix (Pre-Hashing Pattern): To safely support passphrases of arbitrary length without truncation risk, pre-hash the password with a fast cryptographic digest or keyed HMAC before passing it into Bcrypt:

// Safe Pre-Hashing Pattern in PHP $pepper = "YourSecureServerSecretPepper"; $preHashed = hash_hmac('sha256', $userSuppliedPassword, $pepper); $finalHash = password_hash($preHashed, PASSWORD_BCRYPT, ['cost' => 12]); // Verification $candidatePreHashed = hash_hmac('sha256', $loginAttemptPassword, $pepper); if (password_verify($candidatePreHashed, $storedHash)) { // Password authenticated successfully! }

5. Production Implementation Examples

Modern programming languages include native, audited implementations of Bcrypt. Never attempt to implement cryptographic algorithms manually from scratch.

PHP 8.2+ Native Implementation:

// Secure hashing on registration $hash = password_hash($userPassword, PASSWORD_BCRYPT, ['cost' => 12]); // Secure verification on login if (password_verify($inputPassword, $hash)) { // Automatically upgrade legacy hashes to higher cost factor if needed if (password_needs_rehash($hash, PASSWORD_BCRYPT, ['cost' => 12])) { $newHash = password_hash($inputPassword, PASSWORD_BCRYPT, ['cost' => 12]); $db->updateUserPassword($userId, $newHash); } }

Node.js (Async Bcrypt):

const bcrypt = require('bcryptjs'); // Hash password during account creation const saltRounds = 12; const hashedPassword = await bcrypt.hash(rawPassword, saltRounds); // Verify password during login const isMatch = await bcrypt.compare(candidatePassword, hashedPassword); if (isMatch) { // Issue JWT or session cookie }

Python (bcrypt library):

import bcrypt # Hash password salt = bcrypt.gensalt(rounds=12) hashed = bcrypt.hashpw(password.encode('utf-8'), salt) # Verify password if bcrypt.checkpw(login_password.encode('utf-8'), hashed): print("Authentication successful")

6. Frequently Asked Questions (FAQ)

Why is Bcrypt preferred over MD5 or SHA-256 for passwords?

MD5 and SHA-256 are general-purpose hashes engineered for maximum speed. Modern GPUs can calculate over 25 billion SHA-256 hashes per second, making offline brute-force attacks trivially cheap. Bcrypt is an adaptive Key Derivation Function that is deliberately slow and memory-intensive, forcing attackers to spend millions of times more hardware power per guessed password.

What is the recommended Bcrypt cost factor in 2026?

A cost factor of 12 (4,096 rounds) is currently recommended for standard web applications. It targets an authentication latency of roughly 250 to 350 milliseconds on modern server CPUs, ensuring strong resistance against brute-force attacks without causing server CPU exhaustion.

Does Bcrypt have a password length limit?

Yes, Bcrypt has a strict architectural limit of 72 bytes due to its underlying Blowfish key schedule. Any characters beyond 72 bytes are silently ignored by the algorithm. To safely support longer passphrases, developers can pre-hash passwords with SHA-256 or HMAC before passing them to Bcrypt.

Why does Bcrypt not require a separate salt column in databases?

Bcrypt embeds the algorithm identifier, cost factor, and the 128-bit salt directly into the resulting modular crypt formatted string (e.g. $2b$12$[22-character salt][31-character digest]). Verification functions extract the salt automatically from the stored hash.