Bcrypt Generator

Bcrypt is deliberately expensive password verification

Bcrypt is a password-hashing function derived from Blowfish’s key schedule. It combines a password, a per-hash random salt, and an adjustable cost to produce a self-describing 60-character record. The verifier does not decrypt that record. It extracts the version, cost, and salt, repeats bcrypt with the candidate password, and checks whether the result matches.

This design serves a narrow purpose: slowing offline guessing after a password database leaks. It is not a general file hash, encryption algorithm, API signature, or encoding. Fast hashes such as SHA-256 are valuable for integrity but are intentionally too fast for direct password storage. Base64 text inside a bcrypt record is formatting, not secrecy.

The page has two separate workflows. Hash Generator accepts a raw password and cost from 4 through 15, automatically generates a salt through bcryptjs, and displays a new hash. Hash Verifier accepts a candidate password and complete bcrypt hash, then reports a match or failure. Computation occurs client-side and is appropriate for learning, fixtures, format inspection, and non-sensitive compatibility tests. Do not enter a real account password into an online bcrypt generator. Production hashing belongs on the trusted server or authentication service.

Read a bcrypt record rather than splitting it apart

A typical value looks like:

$2b$12$abcdefghijklmnopqrstuu................................

The leading identifier describes the bcrypt variant, the two decimal digits encode cost, the next 22 characters encode a 128-bit salt using bcrypt’s custom Base64 alphabet, and the remaining 31 characters encode the derived result. Exact prefixes commonly include $2a$, $2b$, and $2y$, with compatibility depending on the library. This component uses bcryptjs; generated prefix details should be checked against the runtime that will verify them.

Store the entire string in one database column. Do not put the salt in a second column, strip the prefix, convert its Base64, or generate a custom salt unless a migration specifically requires it. Two hashes of the same password should normally differ because salts differ, yet both verify successfully. Salt uniqueness prevents attackers from reusing one calculation across users and defeats precomputed rainbow tables; salts are not secrets.

Generate and verify with the implemented controls

On Hash Generator, replace the example password123 with a clearly disposable test value. Move Rounds (Cost) and wait for the asynchronous calculation. Input or cost changes trigger a debounced rehash, and Generate Hash requests another salted result immediately. Copy writes the record to the clipboard.

Switch to Hash Verifier, enter the same test password, paste one complete generated record, and select Verify Match. Then change one character in the password and confirm verification fails. Changing a character in the hash may produce failure or a parse error surfaced as failure. This confirms behavior, not production hardening: client-side timing, browser extensions, clipboard history, and page state are unsuitable for valuable secrets.

A useful integration test stores a fixed known bcrypt record as a fixture and asserts correct and incorrect passwords. A second test creates a fresh hash and verifies it without asserting exact text, since the random salt makes exact outputs intentionally unstable. Include empty strings according to product policy, long multibyte input, malformed records, unsupported prefixes, and concurrent login requests.

Choose cost by measurement

Bcrypt cost is a base-2 logarithmic work factor. Increasing cost from 10 to 11 roughly doubles key-setup work; moving from 10 to 14 is roughly sixteen times the work. “Rounds” in interfaces often means this cost exponent, not 10 literal iterations.

There is no universal value that guarantees a particular latency. Browser JavaScript, server CPUs, native libraries, containers, and load all differ. Benchmark the production implementation on representative hardware. Select the highest cost that fits the authentication latency budget and expected peak concurrency, leaving capacity for abuse controls and other work. Measure p50 and tail latency, not one laptop run.

Low costs such as 4 are useful for fast unit tests but provide weak breach resistance. Costs 10 through 12 are common historical defaults, not timeless recommendations. Cost 15 can stall this browser and may create a denial-of-service risk if exposed without rate limits. Security comes from calibration, monitoring, and upgrades rather than copying a number from an example.

When a user logs in successfully, inspect the stored cost. If it is below current policy, hash the already verified password with a fresh salt and stronger setting, then replace the record atomically. This opportunistic rehash avoids knowing plaintext later. A forced reset may be needed for dormant accounts or an algorithm migration deadline.

The 72-byte boundary

Traditional bcrypt processes at most 72 password bytes. Behavior beyond that boundary varies by implementation: input may be silently truncated, rejected, or handled by a wrapper. Bytes are not characters; an emoji occupies multiple UTF-8 bytes. Two strings that differ only after byte 72 can therefore verify as equivalent under truncating implementations.

Define and test the exact behavior of every language and service participating in authentication. Do not casually pre-hash passwords to evade the limit because that changes the scheme and can introduce encoding, NUL-byte, and interoperability problems. If long passphrases are a requirement, prefer a modern password-hashing design such as Argon2id with a vetted library and documented input handling. Existing bcrypt deployments need an explicit, versioned migration rather than an invisible transformation.

Unicode introduces another decision. Visually identical strings can have different code-point sequences. Normalizing only during login locks users out; normalizing before both enrollment and verification changes what counts as the password. Document the policy, preserve exact submitted bytes consistently, and test cross-platform input methods.

Production storage architecture

Generate salts with a cryptographically secure random source through a maintained bcrypt library. Store only the complete bcrypt record and account metadata; never log the raw password. Transmit credentials over TLS, protect reset and enrollment routes, and keep session tokens separate from password records.

A server-side pepper may be applied through a carefully designed scheme and stored in a secret manager or hardware-backed service outside the database. It can help if only the database leaks, but complicates rotation and disaster recovery. A pepper does not replace unique salts, adequate cost, MFA, breached-password screening, or login throttling.

Compare through the library’s verify function, not by extracting the salt and using ordinary string logic. Return one generic authentication failure for an unknown user and a wrong password. Consider a dummy hash for nonexistent accounts to reduce obvious timing differences, while recognizing that network timing defenses require measurement.

Rate-limit by several signals rather than permanently locking an account an attacker can target. Monitor credential stuffing, offer MFA or passkeys, invalidate risky sessions after reset, and ensure backups protect hashes as sensitive data. Hashing limits damage after disclosure; it does not prevent phishing, malware, reuse, or weak reset flows.

Common implementation errors

• Comparing a newly generated hash string with the stored string. Fresh salts ensure those strings differ; use compare.
• Reusing one salt for every user or storing a hand-built salt with low entropy.
• Calling bcrypt “encrypted” and designing a way to decrypt passwords.
• Assuming a cost measured in browser JavaScript predicts native server performance.
• Keeping plaintext in analytics, exception traces, request capture, or queues.
• Truncating a 60-character database field through an undersized column or whitespace cleanup.
• Upgrading cost for every login before verifying, which wastes work and can create inconsistent state.

FAQ

Why does bcrypt generate a different hash each time?

Each generation uses a new random salt. Different records for the same password are expected, and each complete record carries what verification needs.

Can I verify bcrypt without knowing the salt?

Yes. The salt and cost are encoded in the stored record. Supply that whole record and the candidate password to the library.

Is bcrypt better than SHA-256 for passwords?

Bcrypt is designed to be tunably slow, while SHA-256 is designed to be fast. For new systems, also evaluate Argon2id, which can impose memory cost as well as CPU work.

Does a higher cost make a weak password strong?

It makes each guess more expensive but does not add password entropy. Block known-compromised passwords and encourage long, unique credentials.

Is this online bcrypt generator safe for production passwords?

No online demo should receive a valuable password. Use it with disposable data for development, then hash real credentials inside the trusted production boundary.