Bcrypt Password Hash Generator

Why Password Hashing Matters — and Why MD5/SHA Are Wrong

Password storage is one of the most commonly misunderstood security topics in web development. The question is not just should I hash passwords? — it's which algorithm should I use? and the answer matters enormously. Using the wrong algorithm is as dangerous as storing plain text.

The Core Problem: Speed

MD5, SHA-1, SHA-256, and SHA-512 are cryptographic hash functions designed to be fast. That speed is valuable for file checksums and digital signatures. For passwords, it is catastrophic.

A modern GPU can compute approximately:

• 100 billion MD5 hashes per second
• 25 billion SHA-256 hashes per second
• 4 million bcrypt (cost 12) hashes per second — GPU-resistant, runs on CPU
• 10 thousand Argon2id hashes per second — memory-hard, kills GPU farms

If an attacker steals your database and the passwords are hashed with MD5, they can try every common password and billions of variations in seconds. With bcrypt at cost 12, the same attack takes thousands of years. The algorithm's intentional slowness is the entire point.

How Bcrypt Works

Bcrypt was designed in 1999 by Niels Provos and David Mazières specifically for password hashing. Three properties make it suitable:

1. Adjustable cost factor. The algorithm runs 2^cost iterations. Increasing cost by 1 doubles the computation time. This lets you increase security as hardware improves without changing your verification logic or rehashing stored passwords proactively — just rehash on the next successful login.
2. Automatic salting. Every hash includes a cryptographically random 128-bit salt generated fresh for each password. This means two users with the same password have completely different hashes. It makes rainbow table attacks and lookup tables useless — an attacker must brute-force each password independently.
3. CPU-bound algorithm. Bcrypt is based on the Blowfish cipher, which is designed to be resistant to GPU acceleration. GPUs excel at parallelising simple operations; bcrypt's memory access pattern is specifically designed to defeat this.

Choosing the Right Cost Factor for Production

The right cost factor is the highest value your server can compute within an acceptable login time. A commonly recommended target is 250–500ms per hash on your production hardware. Here is a rough guide by typical server type:

OWASP recommends cost 10 as a minimum. PHP's password_hash() defaults to cost 12 (from PHP 8.0). In Node.js, bcrypt and bcryptjs default to 10 rounds — consider increasing to 12. In Python, bcrypt.hashpw() takes rounds as a parameter; default is 12.

Bcrypt vs Argon2 vs scrypt — Which Should You Use?

If your platform supports it, Argon2id is the modern recommendation (winner of the Password Hashing Competition, 2015). It adds memory-hardness — attackers need large amounts of RAM per hash attempt, which makes GPU and ASIC farms massively more expensive.

• Argon2id — best for new systems (PHP 7.2+ via Sodium, Python passlib, Node.js argon2)
• bcrypt — excellent, universally supported, use if Argon2 is unavailable
• scrypt — memory-hard but harder to tune correctly; use Argon2 instead
• PBKDF2 — acceptable only if bcrypt/Argon2 are unavailable; not memory-hard
• MD5/SHA-* — never for passwords, even with salting

Code Examples

PHP

// Hash a password (cost 12 is default in PHP 8.0+)
$hash = password_hash($plaintextPassword, PASSWORD_BCRYPT, ['cost' => 12]);

// Verify a password against a stored hash
if (password_verify($plaintextPassword, $storedHash)) {
    // Login success
    // Check if rehash needed (e.g. cost factor increased)
    if (password_needs_rehash($storedHash, PASSWORD_BCRYPT, ['cost' => 12])) {
        $newHash = password_hash($plaintextPassword, PASSWORD_BCRYPT, ['cost' => 12]);
        // Update $newHash in database
    }
}

Node.js (bcrypt package)

const bcrypt = require('bcrypt');
const saltRounds = 12;

// Hash
const hash = await bcrypt.hash(plaintextPassword, saltRounds);

// Verify
const match = await bcrypt.compare(plaintextPassword, storedHash);
if (match) { /* login success */ }

Python

import bcrypt

# Hash (12 rounds)
password = b"my-password"
hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12))

# Verify
if bcrypt.checkpw(password, hashed):
    print("Password matches")

For new PHP projects, consider password_hash($pw, PASSWORD_ARGON2ID) — available since PHP 7.3 with the Sodium extension. For new Python projects, use argon2-cffi. For new Node.js projects, use the argon2 package.

Frequently Asked Questions

Why can't I use MD5 or SHA-256 for passwords?

Both are designed to be fast — billions of hashes per second on modern hardware. That speed lets attackers brute-force your entire password database quickly. Use bcrypt, Argon2, or scrypt instead — their intentional slowness is the protection.

What cost factor should I use in production?

Choose the highest value that hashes within 250–500ms on your production server. Cost 12 is a good starting point. Benchmark it on your actual hardware before deploying. OWASP recommends cost 10 as minimum.

Does bcrypt automatically add a salt?

Yes. Every bcrypt call generates a fresh random 128-bit salt, stored as part of the hash string. You do not manage salts separately. This means the same password produces a different hash every time.

What is the difference between bcrypt, Argon2, and scrypt?

All three are designed for passwords. Bcrypt is CPU-bound and universally available. Scrypt and Argon2 add memory-hardness (require large RAM per hash), defeating GPU farms. Argon2id is the modern recommendation for new systems where you can use it.

What does a bcrypt hash string look like?

Format: $2b$12$[22-char salt][31-char hash] — always exactly 60 characters. $2b$ is the version. 12 is the cost factor. The cost and salt are embedded in the hash, so verification only needs the plain password and the full hash string.