Bcrypt Hash Generator & Verifier

Fast Hash Functions Are a Security Liability for Passwords

When developers store passwords using MD5 or SHA-256, they are applying general-purpose hash functions that were designed to be as fast as possible. A modern GPU can compute 10–100 billion SHA-256 hashes per second. If an attacker steals a database of SHA-256-hashed passwords, they can try every 8-character password combination in minutes. The LinkedIn breach (2012) exposed 117 million SHA-1-hashed passwords: the majority were cracked within days. This is not a failure of the passwords themselves — it is a failure of the hash function chosen to store them. Bcrypt was designed specifically to address this: it is intentionally, configurably slow, and its slowness is the security feature.

The Cost Factor — Adaptive Security Against Faster Hardware

The cost factor (also called work factor or rounds) controls the number of internal iterations: 2^cost. Cost 10 means 1,024 iterations; cost 12 means 4,096; cost 14 means 16,384. Each increment doubles the computation time — both for legitimate hashing on your server and for an attacker trying to crack a stolen hash. The OWASP ASVS recommendation is to target approximately 100ms per hash on your production hardware, then select the cost factor that achieves this. As hardware improves over time, you can increment the cost factor for new registrations and password changes, while old hashes (with lower cost) remain valid and verifiable. This is bcrypt's "adaptive" property — security stays calibrated to current hardware without requiring any database migration.

Built-in Salt — Why Every Bcrypt Hash Is Unique

Every bcrypt hash includes a randomly generated 16-byte salt, stored as part of the hash string itself. This salt is what makes the $2b$ prefix format self-contained: the cost factor, the salt, and the hash are all encoded in a single 60-character string. Two users with identical passwords receive completely different bcrypt hashes because their salts are different. This makes precomputed rainbow table attacks impossible — an attacker who builds a table of common passwords and their hashes will find no matches, because the hashes in your database were computed with unique salts that did not exist when the table was built. Each cracking attempt must be made individually, against a single hash, at the full computational cost set by the cost factor.

Hash Mode vs Verify Mode

Hash mode generates a new bcrypt hash from a plaintext password. Enter the password, set the cost factor with the slider, and click Generate. The resulting 60-character string (starting with $2b$) is what you store in your database — never the plaintext. Verify mode checks whether a plaintext password matches an existing bcrypt hash. Paste the stored hash into the Hash field, enter the password to test, and click Verify. The tool extracts the cost factor and salt from the hash string, recomputes the hash with those parameters, and compares the result. A green ✓ means they match; a red ✗ means they do not. This is exactly how production bcrypt verification works in every language library.

Bcrypt vs Argon2 vs PBKDF2 — The Alternatives

All three are OWASP and NIST-recommended password hashing functions, all vastly superior to MD5 or SHA-256 for this purpose. Bcrypt has the longest track record (in production since 1999) and the best library support across all major languages and frameworks. It is CPU-bound — it consumes computational time. Argon2 (winner of the Password Hashing Competition 2015) is additionally memory-hard, requiring substantial RAM during computation, which makes GPU and ASIC attacks more expensive relative to server-side verification. PBKDF2-SHA-256 is FIPS 140-2 certified and mandated in some US government and financial sector applications. For most web applications, bcrypt at cost 10–12 is the right choice — it is widely audited, has near-universal library support, and has been battle-tested against real-world breaches for over two decades. Pair this with our Password Generator to create strong passwords before hashing them.

Deploying Bcrypt in Production — What This Tool Is and Is Not

This browser tool uses PBKDF2-SHA-256 via the Web Crypto API to produce a bcrypt-compatible hash format ($2b$) for demonstration, learning and testing purposes. For production applications, always use a server-side bcrypt library: bcryptjs or bcrypt for Node.js, passlib.hash.bcrypt for Python, spring-security BCryptPasswordEncoder for Java, password_hash() with PASSWORD_BCRYPT for PHP, and Go's golang.org/x/crypto/bcrypt package. These libraries implement the full Blowfish-based Eksblowfish key setup of the original bcrypt algorithm, not PBKDF2. Use this tool to understand bcrypt behaviour, test hash format parsing, and demonstrate the cost factor's effect on computation time.

Your Password Never Leaves Your Browser

All hashing uses the Web Crypto API (PBKDF2-SHA-256) running entirely in your browser tab. Your password is never transmitted to ToollyX servers. This is safe for testing with real passwords during development. For production systems, move password hashing to the server side where cryptographic operations should live — a browser is not the right execution environment for authenticating real users.

✓Verified by ToollyX Team · Last updated June 2026