← Takora

bcrypt Hash & Verify

One-Way Password Hashing That Survives Database Leaks

When your user database leaks, the damage depends on how passwords were stored. Plain text means instant account takeover. A fast hash like MD5 or SHA-256 lets attackers compute billions of guesses per second. bcrypt solves this by design: it is a one-way, salted, deliberately slow hashing algorithm built specifically for passwords. You never need to reverse it, because verification re-hashes the candidate and compares. Reach for bcrypt whenever you store credentials, build a login flow, or migrate a legacy password table, because it makes offline brute force economically hopeless.

How to Hash a Password

  1. Type or paste the password you want to protect into the input field.
  2. Choose a cost factor — 10 is the sensible default; use 12 for higher-security accounts.
  3. Click the hash button and copy the full string, which embeds the version, cost, salt, and checksum.
  4. Store the entire hash in your database column; never trim or reformat it.
  5. Discard the original password immediately — the hash alone is all you ever keep.
  6. Verify by hashing the candidate later with the same tool and comparing the results.

Reading the Hash Format

A bcrypt hash is self-describing. Each part tells you how it was produced.

PartMeaning
$2a$10$Version 2a, cost factor 10
N9qo8uLOickgx2ZMRZoMye22-character random salt
...checksum31-character one-way digest

A full example looks like $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy. Because the salt is random, hashing the same password twice produces two different hashes — that is expected and correct.

Choosing a Cost Factor

Verification is the same operation as hashing: the candidate password is hashed with the salt stored in the existing hash, and the tool compares the resulting digest. This design keeps verification fast for legitimate users while forcing attackers to pay the full cost for every guess in an offline attack. It is also why bcrypt is recommended by OWASP and most security frameworks for storing account credentials.

Tips for Best Results

Frequently Asked Questions

Is bcrypt an encryption algorithm?

No. Encryption is reversible with a key, while bcrypt is a one-way hash. You cannot decrypt a bcrypt hash; you can only verify guesses against it.

Why does the same password produce different hashes?

Each hash embeds a random 22-character salt, so identical passwords yield different outputs. Verification extracts the salt from the stored hash and re-derives the digest.

What does the cost factor actually control?

The cost factor is a power-of-two work multiplier. Cost 11 is twice as slow as 10, and each increment doubles the time needed to compute one hash.

What is the maximum password length for bcrypt?

bcrypt only processes the first 72 bytes of input. Longer passwords are silently truncated, so validate length on your own before hashing.

Is bcrypt still secure in 2026?

Yes, for passwords. It remains a recommended choice; newer schemes such as Argon2id offer similar or better resistance, but bcrypt is not broken.

Why not use SHA-256 for passwords?

SHA-256 is fast by design, which lets attackers try trillions of guesses per second. bcrypt's work factor and salt neutralize that speed advantage.

Should I use bcrypt for API keys too?

Yes, for long-lived secrets. A random key with high entropy works fine with bcrypt, though a keyed hash like HMAC is also a valid alternative.

Do two users with the same password get the same hash?

No. Each hash carries a unique random salt, so identical passwords produce completely different hashes. An attacker cannot tell that two accounts share a password.

Can I recover a password from its hash?

No. That is the entire point. The only path is guessing candidates and checking them, which the cost factor deliberately makes slow.

Related Tools