PasswordHive

Generate & Verify Bcrypt Hashes — Free Password Hashing Tool

Generate secure bcrypt hashes for password storage with configurable cost factor (salt rounds). The industry-standard algorithm for hashing passwords securely. Unlike MD5 or SHA, bcrypt is designed to be computationally intensive, making brute force attacks impractical.

Industry Standard
Auto-Salted
Brute Force Resistant
10
4 (Fastest) 14 (Most Secure)

Estimated time: ~100ms

Click "Generate Hash" to create
Copied to clipboard!

Note: Bcrypt hashing runs in your browser using JavaScript. For production, use server-side implementations.

Why Bcrypt?

Bcrypt is the gold standard for password hashing. Here's why security experts recommend it.

Intentionally Slow

Unlike fast hashes, bcrypt is designed to be slow. This dramatically increases crack time, making brute force attacks impractical.

Automatic Salting

Each hash includes a unique random salt, preventing rainbow table attacks. Two identical passwords produce different hashes.

Configurable Cost

The cost factor lets you increase security over time as hardware improves. Double the cost = double the hashing time.

Battle Tested

Used since 1999, bcrypt has withstood decades of cryptographic analysis. It's trusted by major organizations worldwide.

GPU Resistant

Bcrypt's memory-hard design makes it resistant to GPU-based cracking, unlike SHA variants that GPUs process quickly.

Wide Support

Available in virtually every programming language. Easy integration with existing systems and frameworks.

Anatomy of a Bcrypt Hash

Understanding the structure helps you work with bcrypt effectively.

$2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
$2b — Algorithm identifier (2a, 2b, or 2y variants)
10 — Cost factor (2^10 = 1,024 iterations)
N9qo8uLOickgx2ZMRZoMye — 22-character salt (128 bits, base64 encoded)
IjZAgcfl7p92ldGxad68LJZdL17lhWy — 31-character hash (184 bits, base64 encoded)

Bcrypt vs Other Password Hashing Algorithms

Choosing the right password hashing algorithm is critical for security. Here's how bcrypt compares to other popular options.

Comparison of password hashing algorithms including bcrypt, Argon2, scrypt, and PBKDF2
Algorithm Year GPU Resistance Memory Hard Recommendation
Bcrypt Moderate Partial (4KB) Excellent choice
Argon2id High Yes (configurable) Best for new apps
scrypt High Yes Good alternative
PBKDF2 Low No Compatibility only
SHA-256 None No Never for passwords
MD5 None No Never use

Bcrypt Cost Factor Timing Benchmarks

The cost factor (also called work factor or salt rounds) determines how computationally expensive the hash operation is. Higher values = more security but slower processing.

Bcrypt cost factor timing benchmarks on modern hardware
Cost Factor Iterations ~Time (Modern CPU) Use Case
4 16 ~1ms Testing only
8 256 ~40ms Legacy systems
10 1,024 ~100ms Recommended minimum
12 4,096 ~300ms Good for most apps
14 16,384 ~1.2s High security
16 65,536 ~5s Maximum security

"The ideal cost factor should result in 250-500ms hashing time on your production hardware. This balances security with user experience during authentication."

— OWASP Password Storage Cheat Sheet

Bcrypt Implementation Examples

How to use bcrypt password hashing in popular programming languages. Always use established libraries—never implement cryptographic functions yourself.

Node.js (bcrypt) npm install bcrypt 
const bcrypt = require('bcrypt');

// Hash a password
const saltRounds = 12;
const hash = await bcrypt.hash(password, saltRounds);

// Verify a password
const match = await bcrypt.compare(password, hash);
PHP (built-in) PHP 5.5+ 
// Hash a password
$hash = password_hash($password, PASSWORD_BCRYPT, [
    'cost' => 12
]);

// Verify a password
$valid = password_verify($password, $hash);
Python (bcrypt) pip install bcrypt 
import bcrypt

# Hash a password
salt = bcrypt.gensalt(rounds=12)
hashed = bcrypt.hashpw(password.encode(), salt)

# Verify a password
valid = bcrypt.checkpw(password.encode(), hashed)

Frequently Asked Questions

Evaluate Password Security
Previous Tool
Hash Generator
Next Tool
WordPress Hash Generator

Complete Guide to Bcrypt Password Hashing

Bcrypt has been the cornerstone of secure password storage for over two decades. Developed by Niels Provos and David Mazières in , this algorithm remains one of the most trusted methods for hashing passwords. This comprehensive guide explains why our bcrypt generator produces hashes that remain secure against modern attacks, and how to implement bcrypt correctly in your applications.

The Problem Bcrypt Solves

Fast hash algorithms like MD5 and SHA were designed for speed—verifying file integrity, creating checksums. This speed becomes a liability for passwords. Modern GPUs can compute billions of SHA-256 hashes per second , making brute force attacks frighteningly practical.

Bcrypt flips the script. By incorporating an expensive key setup phase based on the Blowfish cipher, bcrypt deliberately slows down hashing. What takes microseconds with SHA-256 takes hundreds of milliseconds with bcrypt. An attacker who could try 10 billion SHA guesses per second might only manage 10,000 bcrypt guesses—a million-fold reduction in attack speed.

Understanding the Cost Factor (Salt Rounds)

The cost factor (also called work factor or salt rounds) determines how computationally expensive hashing becomes. It's a power of 2: cost 10 means 2^10 = 1,024 iterations of the key derivation function. Each increase doubles the time required. Cost 10 might take 100ms; cost 11 takes 200ms; cost 12 takes 400ms.

Choose your cost factor based on your production hardware, targeting 250-500ms per hash . Yes, that seems slow for login, but users won't notice the difference, and it devastates attackers. Increase the cost factor over time as Moore's Law provides faster hardware. Start at 10-12 for most applications today.

Automatic Salting Explained

Bcrypt automatically generates a 128-bit random salt for each password. This salt is stored as part of the hash string itself, so you don't need to manage salts separately. When verifying, bcrypt extracts the salt from the stored hash and uses it to hash the candidate password.

Salting defeats rainbow tables—precomputed tables mapping common passwords to their hashes. Without salts, attackers could look up "password123" → hash instantly. With unique salts, they'd need a separate rainbow table for each user—computationally infeasible. Even if two users share the same password, their bcrypt hashes will differ.

Common Bcrypt Mistakes to Avoid

❌ Using a cost factor that's too low
Cost factors below 10 are too fast on modern hardware. Attackers can crack millions of hashes quickly. Always benchmark on your production servers and aim for 250-500ms.
❌ Truncating passwords before hashing
Bcrypt has a 72-byte limit on password length. If users can enter longer passwords, consider pre-hashing with SHA-256 first, or use Argon2 instead.
❌ Storing hashes with the wrong encoding
Bcrypt hashes are ASCII strings. Don't base64-encode them again or store them as binary. The hash string includes everything needed for verification.
❌ Not handling timing attacks
Use constant-time comparison functions provided by bcrypt libraries. Never compare hashes with == in languages where this isn't constant-time.

Implementation Best Practices

Always use your language's standard bcrypt library rather than implementing yourself—subtle bugs can compromise security. Most modern frameworks include bcrypt: PHP's password_hash(), Python's bcrypt library, Node's bcrypt package. Never store plain-text passwords, even temporarily. Generate strong passwords and verify their strength before hashing.

Plan for cost factor increases. Store the hash (which includes the cost factor) and periodically rehash on successful logins when you raise the cost. This migrates users seamlessly to stronger protection. Enforce password policies so bcrypt doesn't have to protect weak passwords alone.