Bcrypt Password Hasher and Salt Verifier

Generate bcrypt hashes with custom work factors, parse the embedded salt, verify passwords, and measure real computation delays - entirely client-side.

// Panel A: Hash Generator
4 15
Warning: cost > 12 can freeze the browser tab for several seconds. Proceed with care.
Computing... CPU working
// Panel B: Hash Verifier
Verifying... CPU working
Key Terms Explained
Bcrypt
A password hashing algorithm designed in 1999 by Niels Provos and David Mazieres. It is intentionally slow, incorporates a random salt, and exposes a tunable cost parameter to stay resistant against hardware advances.
Cryptographic Hash
A one-way mathematical function that transforms input data into a fixed-size digest. It is deterministic, fast in one direction, and computationally infeasible to reverse. The same input always produces the same output.
Salt
A unique random value generated for each password before hashing. Bcrypt embeds the salt directly into its output string, so no separate storage is needed. The salt ensures two identical passwords produce completely different hashes.
Work Factor (Cost)
The log-base-2 exponent controlling how many internal rounds Bcrypt performs. A cost of 10 means 2^10 (1024) rounds. Increasing the cost by 1 doubles the computation time, making future hardware improvements manageable by simply raising the cost.
Brute-Force Attack
An attack strategy that systematically tries every possible password combination until the correct one is found. Bcrypt defeats this by making each individual guess expensive to compute, limiting an attacker to thousands of attempts per second rather than billions.
Rainbow Table
A precomputed lookup table mapping millions of common passwords to their hash values, allowing instant hash-to-password reversal without per-hash computation. Bcrypt's unique per-password salt makes rainbow tables useless against it.
Key Stretching
The technique of deliberately making a hashing function slow by repeating its internal operations many times. Bcrypt, PBKDF2, scrypt, and Argon2 all use key stretching. The goal is to make each password guess require significant CPU time.
Plaintext Password
The raw, human-readable password before any cryptographic transformation. Plaintext passwords must never be stored in databases. Only a Bcrypt hash of the plaintext should be persisted, verified later by re-hashing and comparing.

The Complete Guide to Bcrypt Password Hashing

If you are building an application that stores user passwords, Bcrypt is one of the best-validated choices available. This guide explains not just how to use this tool, but why Bcrypt works the way it does - and what those timing numbers you see actually mean for your security posture.

How to Use This Tool

Start in Panel A. Type any password into the Plaintext Password field (the eye icon toggles visibility). Set the Work Factor slider - 10 is the OWASP-recommended minimum for most applications. Click "Compute Hash" and wait: the spinner shows the CPU is actively working. When done, the full Bcrypt hash appears in a copyable code block, along with the exact millisecond duration of the operation. The Hash Anatomy section below it breaks the output string into its four components.

To verify a password against a known hash, paste the hash into Panel B's "Hash to Verify" field, type the candidate password, and click "Verify Hash." You will see either a green "Valid Match" or a red "Invalid Hash" indicator, both with their own timing measurement. Critically, valid and invalid verifications take the same amount of time - this is deliberate timing-attack resistance built into Bcrypt.

Reading the Bcrypt Output String

A Bcrypt hash like $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy has four parts separated by dollar signs. The algorithm identifier (2a, 2b, or 2y) specifies the Bcrypt version. The cost (10) is the log-base-2 work factor. The remaining 53 characters encode the 16-byte salt (22 chars in Bcrypt's modified Base64) and the 24-byte hash digest (31 chars) concatenated together. This self-contained format is intentional: one string has everything needed to verify the password later without consulting any external table.

Why the Timing Numbers Matter

The milliseconds shown under each operation are not a performance metric to minimize - they are a security metric to maximize. A hash that takes 100ms means an attacker limited to one machine can try roughly 10 passwords per second. Across a GPU cluster that could normally crack MD5 at billions of hashes per second, the attacker is effectively stopped. Observe how each increase of 1 in the cost slider doubles the time: that is exponential growth working in your favor. Benchmark different cost factors on your target server hardware using this tool, then choose the highest value your response time budget allows.

Client-Side vs. Server-Side Hashing

This tool hashes entirely in your browser using the bcryptjs library - nothing leaves your machine. This is safe for exploration and testing. In a real application, however, password hashing must happen server-side. If you hash on the client and send the hash to the server, the hash itself becomes the credential. An attacker who steals your hash database can authenticate directly without ever knowing the original password. The browser should send the raw password over HTTPS; the server should hash it, then store only the hash.

Frequently Asked Questions

Why is Bcrypt so slow on purpose? ▼
Bcrypt is intentionally slow because slowness is the defense. When verifying one password takes 100ms on a modern server, a legitimate user barely notices. But an attacker trying billions of passwords per second is reduced to a few thousand guesses per second - making brute-force attacks computationally infeasible. This deliberate slowness, called key stretching, is the core security design of Bcrypt.
What is the difference between encryption and hashing? ▼
Encryption is reversible: you can decrypt ciphertext back to plaintext if you have the key. Hashing is a one-way function: once a password is hashed, there is no algorithm to reverse it back to the original. Bcrypt is a hashing function, not encryption. Databases should store password hashes, never encrypted passwords, because encryption keys can be stolen. With a hash, even if the database is breached, attackers cannot recover the original passwords directly.
How does a salt prevent rainbow table attacks? ▼
A rainbow table is a precomputed database of hash values for millions of common passwords. Without a salt, two users with the same password produce the same hash, and attackers can look up hashes instantly in a rainbow table. Bcrypt automatically generates a unique random salt for every hash. This salt is embedded in the output string. Even if two users have identical passwords, their hashes will be completely different, making rainbow tables useless - the attacker would need a separate table for every possible salt.
Is it safe to generate hashes directly in my web browser? ▼
Yes, for testing and learning purposes. This tool uses the bcryptjs library, which runs entirely in your browser's JavaScript engine. No data is sent to any server. However, for production systems you should hash passwords server-side - client-side hashing in a real application means the hash becomes the password, which shifts the attack surface rather than eliminating it. Use this tool to understand Bcrypt behavior and measure work factor timing, then implement server-side hashing in your backend.
What work factor should I use for Bcrypt? ▼
The OWASP recommendation as of 2024 is a minimum work factor of 10, targeting approximately 100ms of computation time per hash on your production server hardware. Higher factors give stronger protection but increase server load. Use this tool's timing output to benchmark different cost factors on your own machine and choose the highest value that keeps response times acceptable for your application's authentication flow.