Bcrypt Generator

SHA-256 and MD5 are designed to be fast — a modern GPU can compute billions of SHA-256 hashes per second. That speed is catastrophic for password hashing: an attacker can brute-force billions of password guesses per second. Bcrypt is intentionally slow: a single hash computation takes milliseconds at cost factor 10, which limits an attacker to a few hundred guesses per second even with powerful hardware. Never use MD5, SHA-1, or even SHA-256 directly for password hashing — use bcrypt, Argon2, or scrypt.

Cost factor 10 (2^10 = 1,024 iterations) is the OWASP-recommended minimum for most applications and produces a hash in about 100ms on modern hardware. Use cost factor 12 for systems handling sensitive data like financial accounts. Each increment doubles the computation time: factor 12 takes 4x longer than factor 10. Test on your actual server hardware and aim for 100-300ms per hash — slow enough to deter attackers, fast enough not to frustrate legitimate users. Never go below factor 10 in production.

Bcrypt generates a cryptographically random 22-character salt for each hash and embeds it in the output string. The salt ensures that even if two users have the same password, they get different hash values. This defeats rainbow tables (pre-computed hash-to-password mappings) and prevents an attacker from seeing that two accounts share the same password. The salt is stored as part of the hash string ($2b$10$<22-char-salt><31-char-hash>), so you do not need to store it separately.

No. Bcrypt (like all proper cryptographic hash functions) is a one-way function — there is no way to reverse it. The only way to "find" a password from a bcrypt hash is brute force: try millions of candidate passwords until one matches. This is why bcrypt's slowness is a security feature, not a bug. To check if a password is correct, you use the verify function — it re-hashes the input with the salt stored in the hash and compares the result.

The Verify tab extracts the salt and cost factor embedded in the existing hash string, runs bcrypt on the input password using those parameters, and compares the result to the stored hash. If they match, the password is correct. This is how authentication works in web applications: the stored hash never changes, and you verify login attempts by re-computing the hash with the same salt. The process takes the same time as generating a hash, which is intentional.

Yes. Bcrypt truncates passwords at 72 bytes. This means very long passwords (over 72 ASCII characters, or fewer for multi-byte Unicode characters) produce the same hash regardless of what follows the 72nd byte — "password123" and "password123abc..." would hash to the same value if the first 72 bytes match. For applications where users may enter passwords longer than 72 characters, a common mitigation is to SHA-256 the password first, then feed the hash to bcrypt (the hash is 64 ASCII characters, well within the limit).

No. This tool uses a pure JavaScript implementation of bcrypt that runs entirely in your browser. Your password, the generated hash, and all verification results stay on your device. Nothing is transmitted to any server. This makes it safe to generate and test hashes using real passwords during development, though you should use test passwords rather than actual user credentials as a best practice.