Bcrypt Generator & Verifier

Hash passwords with bcrypt and verify passwords against existing hashes. Processing done server-side with PHP's password_hash().

Password

Cost Factor: 12

Higher cost = slower hashing = harder to brute-force. Cost 12 is the recommended default.

Password Bcrypt Hash

Frequently Asked Questions

Bcrypt is intentionally slow, making brute-force and dictionary attacks extremely expensive. It includes a random 128-bit salt automatically, so identical passwords produce different hashes. The cost factor lets you increase work as hardware gets faster. This is why every major security framework recommends bcrypt (or Argon2) over MD5, SHA-1, or other fast hashes for passwords.

The cost factor (also called the "work factor") is the log₂ of the number of iterations. Cost 12 = 2¹² = 4,096 rounds. Each increment doubles the computation time. OWASP recommends a minimum cost of 10, and at least 12 for new applications. Tune it so hashing takes ~250ms–1s on your production server.

How Bcrypt Hashing Works

Bcrypt is a password-hashing function based on the Blowfish cipher, designed to be computationally expensive by design.

Generate Random Salt

PHP's password_hash() automatically generates a 128-bit (22 Base64-character) cryptographically random salt for every call. You never provide a salt manually — this prevents salt reuse vulnerabilities.

Expand Key Over 2^cost Rounds

The password and salt are fed into the EksBlowfishSetup key schedule, which is repeated 2^cost times. At cost 12 that's 4,096 expensive key expansions — far slower than SHA-256 for an attacker.

Embed Metadata in Hash

The 60-character output encodes everything needed to verify: $2y$ (algorithm), 12$ (cost), 22-char salt, and 31-char digest. The salt is embedded, so verification needs only the hash string — never separate storage.

Each call generates a different hash even for the same password, because the salt is random. Use password_verify() — never compare bcrypt hashes with === or strcmp().

Common Use Cases

User Password Storage

The primary use of bcrypt. Hash the password before inserting into the database — never store plaintext. On login, call password_verify($input, $storedHash). Even if the database is breached, the hashes resist cracking.

Migrating Weak Password Hashes

If your app uses MD5 or SHA-1 passwords, migrate to bcrypt on each successful login: verify the old hash, then immediately re-hash with bcrypt and store the new value. Use this tool to test the migration.

Cost Factor Tuning

Use this tool to benchmark different cost factors on your production hardware. Aim for 250ms–1s per hash. Move the cost slider and observe generation time to find the right balance between security and UX.

Verifying Stored Hashes

Use the Verify tab to confirm a password matches an existing bcrypt hash. Useful when debugging authentication issues or testing that a hash stored in the database was generated from the expected password.

API Key & Token Hashing

API keys can be stored as bcrypt hashes rather than plaintext. The user sees the key once at creation; the server stores only the hash and verifies on each request — minimizing exposure if the database is breached.

Security Auditing

Paste a hash from a database dump to verify its format ( $2y$ vs older $2a$ ) and cost factor. A cost below 10 is considered underpowered by today's standards and should be re-hashed on next user login.