Bcrypt Hasher
Hash text with bcrypt cost factors using browser-side crypto libraries.
Bcrypt Hasher
What This Tool Does
- Bcrypt is a password-hashing function designed by Niels Provos and David Mazières, based on the Blowfish cipher, and presented at USENIX in 1999. It incorporates a work factor (cost parameter) that allows the hashing difficulty to scale as computer processors grow faster, ensuring long-term resistance to brute-force and hardware-accelerated attacks. The algorithm works by running an expensive key setup phase, stretching the password into a secure hash key. Standard hashing algorithms like MD5, SHA-1, and SHA-256 are designed to be extremely fast. While high throughput is desirable for file checksums and message digests, it is a liability for passwords. Attackers using modern GPU or ASIC clusters can compute billions of SHA-256 hashes per second, allowing them to crack weak passwords in minutes. Bcrypt deliberately counters this by utilizing a key-stretching algorithm that forces the CPU to spend a significant fraction of a second on each password attempt.
- Bcrypt hashes have a distinct structure. They begin with a version identifier (e.g. $2a$, $2b$, or $2y$), followed by a two-digit cost parameter representing the logarithmic work factor (e.g., 10 or 12), a 22-character salt (128 bits encoded), and a 31-character cipher value (186 bits encoded). The salt is generated randomly for each password, ensuring that identical passwords result in entirely unique hashes. This completely neutralizes rainbow table attacks (pre-computed hash lookup tables) and prevents attackers from detecting users with shared passwords across systems. The ScriptPulse Bcrypt Hasher runs entirely client-side using JavaScript crypto libraries. This enables developers to generate hashes and test candidate passwords against active hashes locally, ensuring that sensitive credentials never leave their browser or transit over the network.
How It Works
- The Bcrypt Hasher processes inputs client-side using an on-demand cryptographic module.
- For hashing, it generates a cryptographically secure 128-bit random salt and combines it with the candidate password.
- It then executes the Blowfish-based key setup phase repeatedly according to the logarithmic cost factor (2^cost iterations).
- For checking, it extracts the salt and cost factor from the provided target hash, runs the same hashing steps on the candidate password, and performs a timing-safe string comparison to verify if the outputs match.
Usage
- Enter the plaintext password candidate you want to hash or check.
- To hash: select your target logarithmic work factor cost (e.g., 10 or 12) and click Generate Hash.
- To check: paste the existing bcrypt hash (starting with $) into the verification field.
- Review the real-time match outcome or inspect the generated hash segments.
- Copy the generated hash directly to populate your seed databases or configuration scripts.
Examples
- Hashing with cost 10: Generating a $2a$10$... hash to use for speed-optimized local development environments.
- Hashing with cost 12: Generating a $2b$12$... hash to mirror modern production security parameters.
- Matching passwords: Validating that input "mySecretPassword" correctly matches the hash $2a$12$R9h/cIPz0gi.URrXRYzUCO757z.H3Q4sWn7Wl5.l4l7X4i.gLhU9e.
- Checking invalid matches: Verifying that an incorrect password fails verification with a timing-safe mismatch status.
- Inspecting hash components: Verifying that $2b$12$dE123... correctly represents version 2b and cost 12.
Real-World Use Cases
- Generating safe database seed password hashes for local user account mockups during development.
- Verifying that a candidate password matches a bcrypt hash pulled from application database tables during manual bug checks.
- Testing different work factor cost parameters (e.g., 10, 12, 14) to benchmark hash computation times on target environments.
- Hashing test credentials manually before inserting them into a test database or API schema payload.
- Troubleshooting authentication issues by verifying if hashed passwords match user registration mock hashes.
Best Practices
- Set the work factor (cost) as high as tolerable for system performance (10 is the practical minimum, 12 is recommended for modern web servers).
- Use a timing-safe equality comparison function when validating password hashes to prevent timing attacks.
- Never store plaintext passwords or plain SHA hashes in user databases; always run them through slow KDFs like bcrypt or argon2.
- Regularly monitor hash verification latency on production servers and update the cost factor dynamically as hardware capabilities grow.
- Perform password hashing on a secure server environment, utilizing local utilities only for testing, mock seeding, and diagnostics.
Common Mistakes
- Using a weak cost factor (like 4 or 6) that allows fast brute-force searches on commodity hardware.
- Truncating input passwords; standard Bcrypt ignores any characters beyond the first 72 bytes, which can cause security holes in long passphrases.
- Implementing custom timing-vulnerable comparison functions instead of using standard bcrypt verification libraries.
- Failing to normalize character encoding (e.g., UTF-8), which can lead to login failures if client and server parse unicode characters differently.
- Hashing the hash: running MD5 or SHA before passing the password to bcrypt, which does not add safety and can create collation bugs.
Limitations
- Results should be validated in your target runtime before production use.
- Extremely large input payloads may be constrained by browser memory and performance limits.
Technical Reference Guide
- Bcrypt: One-way password hashing algorithm combining salt generation and cost-based key derivation.
- Salt: Random bytes mixed with password before hashing. Prevents rainbow-table attacks.
- Cost factor (rounds): Exponential slowdown per unit. Cost 10 = 2^10 iterations (~100ms). Cost 12 = 2^12 (~250ms).
- Hash output format: $2a$, $2b$, or $2y$ prefix indicates variant. $cost$salt$hash. Example: $2b$12$...
- Verification: Compare plaintext against hash using bcrypt algorithm. Does not decrypt hash; only re-hashes and compares.
- Pepper: Optional server-secret additional to salt, not recommended for simple workflows.
- Adaptive hashing: Bcrypt's slowdown increases over time as hardware improves, maintaining security.
Specifications & Standards
FAQ
Why does Bcrypt ignore passwords longer than 72 bytes?
Bcrypt is based on the Blowfish cipher, which has a maximum key size of 72 bytes (576 bits). Any bytes beyond this limit are ignored by the standard algorithm. To handle longer passphrases, some systems pre-hash the input with SHA-256 before passing it to bcrypt, though this requires consistent implementation.
What is the difference between $2a, $2b, and $2y versions?
These represent version revisions of the algorithm. $2a$ is the original version, which had a minor bug in how it handled non-ASCII characters. $2y$ was introduced in PHP to fix this issue, and $2b$ is the current standard version that correctly handles all inputs.
Can a bcrypt hash be decrypted?
No. Bcrypt is a one-way cryptographic hashing function, not an encryption algorithm. It uses mathematical key-stretching that cannot be reversed. You can only verify if a candidate password matches by hashing the candidate and comparing the outputs.
What does the cost parameter represent?
The cost parameter is a logarithmic value representing the number of iterations the hashing engine performs. The actual number of rounds is calculated as 2^cost. A cost of 10 means 1,024 rounds, whereas a cost of 12 means 4,096 rounds, doubling the computation time with each step.
Is it safe to run Bcrypt in the browser?
Yes. All computations occur locally in your browser memory. No credentials or outputs are uploaded, ensuring complete privacy during development. However, production user hashing should always be executed on your secure backend servers.
Why does the same password generate different hashes?
Bcrypt automatically generates a unique random 128-bit salt for every new hash. Because the salt is included in the final hash string, the resulting text is always different even if the input password is identical, preventing rainbow table attacks.
What is a rainbow table attack?
A rainbow table is a precomputed table of passwords and their corresponding hashes. Random salts prevent this because an attacker would need to precompute tables for every possible salt value, which is computationally impossible.
How is Bcrypt different from SHA-256?
SHA-256 is a fast cryptographic hash designed for data integrity, processing gigabytes of data per second. Bcrypt is a slow hashing function designed specifically for passwords, intentionally consuming CPU resources to make brute-force attacks impractical.
Related Tools
Explore related utilities inside the Security Lab workshop for complementary engineering workflows.
View all Security Lab tools