Argon2 vs bcrypt: Which Password Hash to Use?

Here's the claim that gets me quietly disinvited from architecture reviews: for a brand-new system in 2026, whether you choose bcrypt or Argon2 matters far less than the two numbers you feed whichever one wins. Pick either and tune it carelessly, and you've built a hash a rented GPU chews through before lunch.

So let me skip the feature-matrix ritual and go straight to the one property that actually separates these two — memory — and how to set the parameters so an attacker pays real money for every single guess.

Both are slow on purpose

General-purpose hashes like SHA-256 are built to be fast. Password hashes are built to be slow, deliberately, because the only person in a hurry to hash a password a billion times is an attacker who stole your database. bcrypt (Niels Provos and David Mazières, 1999) and Argon2 (the winner of the 2015 Password Hashing Competition) both share that DNA, and both mix in a per-password salt so identical passwords don't produce identical hashes. Neither is encryption — there's no key, and nothing decrypts back. If that whole family is fuzzy, bcrypt password hashing explained is the primer; this post is only about what the two do differently.

The whole fight is about memory

bcrypt is CPU-hard. It leans on processor work but uses a fixed, tiny footprint — about 4 KB of memory per hash. Argon2 is memory-hard: you tell it to burn, say, 64 MB of RAM on every single guess.

Picture a burglar. bcrypt makes them pick a lock at a workbench — irritating, but you can buy a thousand workbenches and pick a thousand locks at once. Argon2 makes each attempt rent an entire warehouse of scratch space, so a thousand parallel guesses means a thousand warehouses.

That's the entire advantage. GPUs and ASICs — the hardware that makes password cracking cheap — pack thousands of cores but comparatively little fast memory per core, so a memory-hard function turns that army of cores into a crowd standing around waiting for RAM. Which is exactly why a modern recommendation for a fresh system leans Argon2.

Use Argon2id, and know its three knobs

Argon2 ships in three variants. Argon2d maximizes GPU resistance but is more exposed to side-channel timing attacks; Argon2i defends against those but gives up a little brute-force resistance; Argon2id is the hybrid that current guidance recommends as the default. Use Argon2id unless you have a documented reason not to.

It exposes three parameters: memory cost (how much RAM per hash), time cost (how many passes), and parallelism (how many lanes). You tune them together toward a target time — more on that in a moment.

bcrypt's sharp edge, and why it's still fine

Now the honest counterpoint, because "newer" isn't "better by default." bcrypt has a real quirk: it only reads the first 72 bytes of a password and silently ignores the rest, so long passphrases need care — some systems pre-hash the input first, which has its own traps. And its fixed 4 KB means it simply can't match Argon2's memory story.

But bcrypt has 25 years of analysis, universal library support in every language you'd name, and no practical break. If you already run bcrypt with an adequate cost factor, ripping it out is rarely the best thing you could be doing with that hour. For the fuller picture of when an algorithm actually "breaks" versus merely ages, MD5 vs SHA-256 vs bcrypt walks each one to its verdict.

The verdict, and the two numbers that beat either name

New system? Reach for Argon2id. Keeping bcrypt? Raise the cost factor — each step from 10 to 11 to 12 doubles the work, and 12 or higher is a sane floor on modern hardware.

But here's the part almost nobody tunes: measure on your hardware. Set the parameters so a single hash takes roughly 250 to 500 milliseconds on the machine that'll actually run in production — slow enough to punish an attacker, fast enough that your login endpoint doesn't fall over under a crowd of real users. A "rounds = 10" copied from a 2012 tutorial is far too fast today, and that stale number does more damage than the algorithm choice ever will.

You can feel the cost-factor effect yourself with the bcrypt hash generator — bump the rounds and watch the delay grow — then confirm a password matches a stored hash with bcrypt compare. And whichever algorithm you land on, the hash is only half the job: a strong hash of a weak password is still a weak password. Generate real ones with the password generator and let the slow hash protect what was already hard to guess.