bcrypt Generator

bcrypt is still one of the safest choices for storing passwords. It is deliberately slow, derives its own salt, and scales against hardware improvements through an adjustable cost parameter. This generator produces a standards-compliant bcrypt hash from a plaintext password so you can seed a test user, migrate an account between systems, or compare values against an existing hash stored in a users.password column.

How to hash a password with bcrypt

  1. 1

    Enter the plaintext password

    Up to 72 bytes — bcrypt silently truncates beyond that.

  2. 2

    Choose a cost factor

    10 is the current default; 12 is common for new systems; 14 is paranoid. Every +1 roughly doubles the hash time.

  3. 3

    A random salt is generated

    16 bytes of salt are drawn from a cryptographic RNG and embedded in the resulting hash string.

  4. 4

    Copy the hash

    The output is a self-describing string like `$2b$12$...` that includes version, cost, salt and digest.

Anatomy of a bcrypt hash

$2b$12$mE2n5YqWjKqT9tXg.OQPoeeHZJ9hdSvOt5wFdRRQwl6yE1vWWY3z6
  |   |  |                      |
  |   |  salt (22 Base64 chars)  digest (31 Base64 chars)
  |   cost (2 digits, 4-31)
  version (2a, 2b, 2y — all bcrypt)

The whole string is 60 characters. Columns typed VARCHAR(60) or CHAR(60) are the standard schema.

Cost factor recommendations

Cost Approx time per hash (2024 CPU) Use case
10 ~80 ms Legacy default, still acceptable
12 ~300 ms Current recommended baseline
13 ~600 ms Higher-security apps
14 ~1.2 s Paranoid; noticeable login delay

Every increment doubles the work factor. If login latency under 500 ms is critical, stay at 10-12.

Version byte: 2a vs 2b vs 2y

  • $2a$ — Original 1999 specification. Most libraries emit 2a hashes.
  • $2b$ — 2014 revision fixing a truncation bug in crypt_blowfish. Preferred for new hashes.
  • $2y$ — PHP-specific tag, functionally equivalent to $2b$.

All three verify against each other; only the tag in the hash string differs.

What bcrypt protects against

  • Rainbow tables — Unique per-hash salt defeats precomputed lookups.
  • GPU/ASIC cracking — The Blowfish key schedule is memory-bound and hostile to GPUs. Not as GPU-hostile as Argon2, but still slow to brute force.
  • Database leaks — The plaintext is never recoverable from the hash without brute force.

What bcrypt does NOT protect against: weak passwords (use a minimum length and check against breach lists), credential stuffing (use a second factor), phishing.

72-byte limit

bcrypt uses only the first 72 bytes of the password. Longer inputs are truncated silently, which is the same reason many libraries now recommend pre-hashing the password with SHA-256 before feeding it to bcrypt. Modern alternatives (Argon2, scrypt) have no such limit.

Frequently Asked Questions

Yes for password storage, at cost ≥ 12. OWASP still lists it as an acceptable algorithm. Argon2id is the preferred new-system choice, but migrating legacy bcrypt hashes is a low-priority concern.

Because the salt is randomly generated per hash. Verification takes the salt from the stored hash, re-hashes the submitted password with it, and compares.

Most libraries do not expose this, and for good reason — predictable salts defeat the purpose. Use the library-generated salt; that is the secure path.

Yes — the work factor is symmetric. Verifying a cost-14 hash takes 16x longer than verifying a cost-10 one. Tune with your login throughput in mind.

Related Tools