Skip to content

A bcrypt hash cannot be decrypted.

Not by this site and not by any other one. Bcrypt is a one way function, so there is no key that unlocks it and no inverse to run. The password was never stored, only the result of grinding it through thousands of rounds.

That is the whole reason it is used. If a hash could be turned back into a password, then anybody who stole your database would have every password in it.

What you can read out of a hash

Three of the four fields are not secret at all. Paste a hash and you get everything it is willing to tell you, which is genuinely useful for working out which library produced it and how expensive it was to make.

Reading happens locally too

What you were probably after

Almost everybody searching for this wants one of four things, and three of them are perfectly possible.

You want to check whether a password is the right one

This one is possible and it is what bcrypt is designed for. Supply the hash and a candidate password and the verifier will tell you whether they match.

Use the verifier

You lost the password to your own account

Nothing in the database will give it back to you, because the plaintext was never stored. Go through the password reset flow, or if you own the system, generate a new hash and write it into the row yourself.

Generate a replacement hash

You need to put a known password into a database

Seeding a test account or fixing a locked out admin does not need decryption at all. Hash the password you want, with the prefix and cost your framework expects, and update the row.

See the framework pages

You are testing how strong the passwords are

On a system you are authorised to test, that means running guesses against the hashes with something like hashcat and seeing which ones fall. It is guessing, not reversing, and bcrypt is deliberately slow at it.

How the cost factor slows that down

Why the sites promising decryption cannot deliver it either

A tool that claims to reverse a hash is doing one of two things. It hashes candidate passwords from a wordlist and checks each result against yours, or it keeps a table of hashes it computed earlier and looks yours up. Both only find passwords that somebody already put on a list.

The lookup table approach barely works against bcrypt at all, because every hash carries its own random salt. A precomputed table would have to be built separately for each of the 2^132 possible salts, so the usual shortcut of computing once and reusing forever does not apply.

That leaves guessing one candidate at a time, at whatever the cost factor makes each attempt cost. This is exactly the situation bcrypt was designed to create.

Questions people ask

Is there any way to decrypt a bcrypt hash?
No. Bcrypt is a one way function and not an encryption algorithm, so there is no key and no inverse operation. The plaintext is not present in the hash in any recoverable form.
What about sites that advertise bcrypt decryption?
They are guessing. Either they hash entries from a wordlist and compare, or they look the hash up in a table of hashes they computed earlier. Both work only for passwords somebody already thought of, and both are slow against bcrypt by design.
How long would it take to brute force one?
At cost 12 a single guess costs roughly 200 milliseconds of CPU time. A short lowercase password still falls quickly with enough hardware. A long random one is out of reach, and the cost factor is the lever that decides where the line sits.
Can I at least get the salt out?
Yes, and the version and cost too. All three are stored in plain sight inside the hash string, which is what the reader on this page shows you. Only the digest is one way.
Is bcrypt encryption or hashing?
Hashing. The confusion comes from the name, since bcrypt is built on the Blowfish cipher, but it uses that cipher to derive a digest rather than to encrypt anything you can get back.

Next