Password Hashing: bcrypt vs Argon2id, and Why Fast Is a Bug

Almost every function you write, you want to be fast. Password hashing is the one exception, and it is the exception that keeps showing up in breach headlines. If a stolen database turns out to be MD5, or SHA-256, or SHA-256 with a salt bolted on, the passwords are effectively already cracked. Not theoretically. Over a weekend, on a gaming GPU somebody already owns.

Here is the number that made it click for me. A single stock RTX 4090, benchmarked with hashcat v6.2.6, runs MD5 at 164.1 billion guesses per second.^[5] The entire space of eight-character lowercase-and-digit passwords is about 2.82 trillion candidates. At that rate, one card walks the whole space in about seventeen seconds. Against SHA-256 on the same card, a bit over two minutes.

Against bcrypt on that same card, at a cost factor that is already considered too low, the attacker gets 184,000 guesses per second instead.^[5] Same silicon, same password, roughly 892,000 times slower. That single ratio is the whole discipline.

A salt is not a speed bump

People reach for a salt as though it fixes the speed problem. It does not. A salt is a unique value stored next to each hash, and it buys you exactly two things. It stops precomputation, so an attacker cannot look your hash up in a rainbow table built years ago. And it makes two users who both picked hunter2 produce two different hashes, so cracking one does not crack the other.^[1]

That is real value, and it is not optional. NIST SP 800-63B says passwords SHALL be salted and hashed, that the salt SHALL be at least 32 bits, and that both the salt and the resulting hash SHALL be stored for each password.^[3] But notice what a salt does not do. It costs the attacker nothing per guess. Salted MD5 is still 164 billion guesses a second. It just means they have to point the GPU at one account at a time.

A pepper is the other thing, and it is worth knowing the difference. A pepper is one secret value shared across every stored password, and the whole point is that it lives somewhere other than the database.^[1] NIST puts it this way: verifiers SHOULD perform an additional iteration of a keyed hashing or encryption operation, using a secret key known only to the verifier. That key is stored separately, ideally inside a hardware security module or a trusted execution environment.^[3] So a leaked database dump on its own is useless. The attacker needs the app server too.

Three knobs, and only one of them really hurts

Modern password hashing functions expose up to three parameters. Time cost, usually written t, is how many passes the function makes. Memory cost, m, is how much RAM one hash computation has to hold. Parallelism, p, is how many lanes run at once.^[2] bcrypt and PBKDF2 give you the first one only. scrypt and Argon2 give you all three.

Turning up time cost is the intuitive move, and it is the weaker one. Doubling the passes doubles the attacker's work, sure. It also doubles yours, and your login endpoint is the thing that has to stay responsive under a credential-stuffing flood. OWASP's general rule is that computing a hash should take under a second, and warns that a work factor set too high is itself a denial-of-service surface.^[1]

Memory cost is different in kind, and this is the part I think most write-ups undersell. A GPU has thousands of cores and a fixed pool of RAM. Cores are cheap and abundant; memory per core is neither. So making a hash need a lot of memory does not slow down one guess so much as it caps how many guesses can happen at the same time, on hardware whose entire advantage is doing things at the same time.

Do the arithmetic on a 24 GiB card. bcrypt's working state is 4 KB per guess,^[4] so about 6.3 million concurrent attempts fit in that memory. Argon2id at the OWASP minimum of 19 MiB per guess fits roughly 1,290. That is a factor of about 4,800 in parallelism, before a single hash is computed. And unlike time cost, it is not something the attacker can buy their way out of cheaply, because the expensive thing on a custom ASIC is exactly the thing you just demanded more of.

The Argon2 authors say this out loud in the RFC, and it is the single most useful sentence in the document: for Argon2d and Argon2id, one pass maximizes the attack costs for a fixed amount of defender time.^[2] Read that again. Given a budget of half a second on your server, you are better off spending it on memory than on passes. The knob everyone instinctively turns is the wrong knob.

The four candidates, and what to actually set

So what do you set? These are the current OWASP Password Storage Cheat Sheet values, quoted rather than remembered, because this is the exact place where a half-recalled number becomes a real weakness.^[1]

• Argon2id, the default for new systems. Minimum m=19456 (19 MiB), t=2, p=1. OWASP lists five configurations it treats as equivalent, trading memory for passes: m=47104 (46 MiB) at t=1, m=19456 (19 MiB) at t=2, m=12288 (12 MiB) at t=3, m=9216 (9 MiB) at t=4, m=7168 (7 MiB) at t=5, all at p=1. RFC 9106 aims much higher where you can afford it, at t=1, p=4, m=2 GiB.^[2]
• scrypt, if Argon2id is not available. N=2^17 (128 MiB), r=8, p=1, with four lower-memory alternatives down to N=2^13 (8 MiB) at p=10.
• bcrypt, for legacy systems. Work factor of 10 or more, as large as your verification server can stand, and enforce a maximum password length of 72 bytes.
• PBKDF2, only if FIPS-140 compliance requires it. 600,000 iterations with HMAC-SHA-256, or 220,000 with HMAC-SHA-512. PBKDF2-HMAC-SHA1 needs 1,400,000 and is legacy only.

Never write your own, and verify in constant time

Two rules that sound like folklore and are not. The first: use a library that implements the whole scheme, salt generation included. Every algorithm above requires the caller to provide a salt, and the standard implementations generate one for you with a cryptographic random source and encode it into the output string.^[1] Hand-rolling salt generation with random() is a real, repeat-offender bug.

The second: never compare hashes with ==. A normal string comparison returns as soon as it finds a differing byte, so how long it takes leaks how many leading bytes matched, one guess at a time. Use the library's own verify function, which compares in constant time. This is the same class of mistake as comparing API tokens or webhook signatures byte by byte, which is one of the recurring findings in the OWASP API security failures that keep shipping.

Which brings up the third thing, the one that actually gets skipped: migration. Your parameters will be too weak in five years. That is not a prediction, it is the design. OWASP's answer is to rehash on successful login, because that is the one moment the plaintext exists on your server.^[1] NIST asks you to store a reference to the scheme and its cost factor with each password precisely so this is possible.^[3]

from argon2 import PasswordHasher
from argon2.exceptions import VerificationError, InvalidHashError

# OWASP minimum: m=19456 KiB (19 MiB), t=2, p=1.
# Tune upward until one hash costs about 0.5s on your login server.
ph = PasswordHasher(memory_cost=19456, time_cost=2, parallelism=1)


def login(user, password: str) -> bool:
    try:
        # Constant-time comparison happens inside verify(). Never use ==.
        ph.verify(user.password_hash, password)
    except (VerificationError, InvalidHashError):
        return False

    # The only moment the plaintext exists on this server, so it is the
    # only moment we can upgrade a hash without asking the user to reset.
    if ph.check_needs_rehash(user.password_hash):
        user.password_hash = ph.hash(password)
        db.save(user)

    return True

Coming from a bcrypt table, the same shape works with one branch: if the stored value starts with $2b$, verify it with the bcrypt library, and on success write back an Argon2id hash. No mass reset, no maintenance window, no user ever notices. The catch OWASP names is that this only reaches users who come back, so set a deadline and expire the stragglers rather than carrying MD5 rows for another decade.^[1]

What I would actually do on Monday

Argon2id, m=19456, t=2, p=1, tuned upward until a single hash costs about half a second on your real login server. A per-password salt from the library, never from you. A pepper only if you have somewhere real to keep the key and a plan for rotating it. Verify through the library's verify function. Rehash on login, and store the parameters with the hash so future-you can tell which rows are stale.

And keep the hashing decision separate from the session decision. What the server hands back after a successful login is its own problem with its own tradeoffs, which I worked through in the comparison of JWTs against server-side sessions. While you are in there, note that hash agility, the ability to swap an algorithm without a migration project, is the same muscle you will need for the post-quantum cryptography migration. Build it once.

The uncomfortable part of all this is how cheap it is. Argon2id is one dependency and one line of configuration. There is no engineering reason left to be storing a fast hash in 2026, and the next breach writeup that says otherwise will not be a story about cryptography. It will be a story about a table nobody looked at.