Is Bcrypt Still Secure?

Yes, with caveats that have nothing to do with its age. Bcrypt at a sensible cost factor is not the weak link in any system I have looked at, and it has outlasted most of the things built to replace it.

Nothing has broken the algorithm

Bcrypt has been in front of cryptographers since 1999 and there is still no shortcut that recovers a password faster than trying candidates one at a time. Compare that to MD5, which had practical collisions by 2004, or SHA-1, which had a public collision in 2017. Bcrypt has had neither, and the design has needed two corrections in a quarter of a century, both of them implementation bugs rather than weaknesses in the construction.

Those two corrections are why the version prefixes exist, and what $2a, $2b and $2y mean covers the story if you have seen the letters and wondered.

What has changed is the hardware

The attack on any password hash is guessing, and guessing has been getting cheaper every year. What protects you is that bcrypt is bad at running on the machines attackers buy. It needs about 4 KB of memory per hash with an access pattern a graphics card cannot pipeline, so a GPU that eats fast hashes by the billion barely gets going.

Published benchmarks for a single high end consumer GPU land roughly here, in guesses per second:

At 1,400 guesses per second, an eight card rig gets through roughly a billion candidates a day. That is plenty for a leaked password list and nowhere near enough for a random passphrase, which is the real shape of the risk.

Where bcrypt genuinely lags

Three things, and only one of them is about strength.

1. 1. Its memory use is fixed at about 4 KB. That was awkward for hardware in 1999 and it is small enough to sit in cache today, so custom silicon and FPGAs close some of the gap that a GPU cannot. Argon2 and scrypt let you demand tens of megabytes per guess, which is expensive to buy in parallel.
2. 2. It reads at most 72 bytes of the password, and most libraries drop the rest without saying so. Not a weakness for ordinary passwords, and a real trap for long passphrases and pre-hashed input.
3. 3. It has one knob. You can make it slower and that is all. Argon2 lets you say how much memory, how much time and how many threads separately, which is a better fit for tuning against a specific machine.

None of those makes a cost 12 hash crackable. They do make Argon2id the better default for something new, and the current OWASP guidance goes further than that. It puts Argon2id first, scrypt second, and says bcrypt "should only be used for password storage in legacy systems where Argon2 and scrypt are not available", with a work factor of 10 as the floor. Worth quoting exactly, because it is stricter than the way bcrypt usually gets described.

The honest answer about migrating

If you run bcrypt at cost 10 or above and store nothing else next to it, changing function is one of the lower value pieces of security work available to you. Raise the cost factor, which costs an afternoon. Then spend the rest of the week on the things that actually lose accounts.

• Rate limiting on the login endpoint, so credential stuffing is not free.
• Rejecting passwords that appear in breach lists, which stops reuse at the door.
• Multi factor authentication for anything with money or admin rights behind it.
• Making sure the reset flow cannot be used to take over an account.

Every one of those defends against attacks that no hash function can touch. Nobody has ever lost a company because their bcrypt cost was 11 rather than 12.

When to actually worry

Worry if the cost factor is 8 or below, if the hashes are unsalted MD5 or SHA-1 wearing a bcrypt column name, or if the same passwords are also sitting in a logging pipeline somewhere. Those are real problems with a real fix.

Otherwise, the comparison of the four functions has the details, and the Argon2 tool is there when you do start something new.