OWASP's Application Security Verification Standard names Argon2id as the preferred password-hashing function, ahead of bcrypt, scrypt, and PBKDF2, and its Cheat Sheet Series publishes concrete starting parameters (for example, roughly 19 MiB of memory with a single iteration, or several iterations with less memory, depending on server load). Frameworks have followed suit at different speeds: Laravel's Hash facade, Django's password hashers, and PHP's own password_hash() all support Argon2id today, though bcrypt often remains the historical default for backward compatibility.
What "memory-hard" actually buys you
Bcrypt's cost factor only slows an attacker down in CPU time. Argon2 additionally forces every single guess to allocate a configurable block of RAM — commonly tens of megabytes per hash. A cloud GPU instance can evaluate billions of cheap hashes per second, but renting enough combined memory bandwidth to run millions of memory-hungry Argon2 attempts in parallel is a fundamentally different, much costlier problem.
Choosing between d, i, and id
- Argon2d — memory access depends on the password itself, giving the strongest GPU resistance but a theoretical side-channel exposure.
- Argon2i — memory access is data-independent, closing that side-channel at a small cost to GPU resistance.
- Argon2id — switches strategy partway through, combining both properties. This is the variant recommended by RFC 9106 and used by default almost everywhere.
Three independent knobs
Unlike bcrypt's single cost factor, Argon2 lets you tune memory, iterations, and parallelism separately. That matters operationally: a serverless function with a tight memory ceiling might need to trade memory for more iterations, while a dedicated auth server with spare RAM can afford the reverse — something a one-dimensional cost parameter simply can't express.
Why this matters
- Picking a modern hashing algorithm for a new authentication system instead of MD5 or plain SHA-256.
- Understanding why Argon2 is specifically harder to crack on rented GPU or cryptomining hardware.
- Planning a migration off bcrypt or PBKDF2 as part of a security review.
The parallelism trap
Parallelism looks like a free performance win — more threads, faster hashing on a multi-core server. But an attacker with the same multi-core (or multi-GPU) hardware gets the identical speedup on every guess. Setting parallelism to match your server's actual core count is safe; setting it higher "for headroom" just hands the attacker a proportional discount.