What is Argon2?
Argon2 is a password hashing and key derivation function designed by Alex Biryukov, Daniel Dinu and Dmitry Khovratovich of the University of Luxembourg. It won the Password Hashing Competition, an open contest held from 2013 to 2015 to find a successor to older schemes, and the IETF published it as RFC 9106 in 2021. Its defining feature is that every hash requires a large, configurable amount of memory, which makes mass guessing on GPUs and custom chips far more expensive than with bcrypt or PBKDF2.
Why memory hardness matters
Attackers crack stolen hashes on graphics cards because a GPU runs thousands of simple computations in parallel. That works well when each guess needs only a few kilobytes. Argon2 forces each guess to fill and repeatedly read a block of memory sized by the defender. Suppose a site uses 64 MiB per hash. A graphics card with 24 GiB of memory can then hold only about 384 guesses in progress at once, however many thousands of cores it has, so memory rather than processing power limits the attack. The legitimate server spends the same 64 MiB for a fraction of a second per login.
Variants and parameters
- Argon2d chooses memory locations based on the password, which resists GPU attacks best but can leak information through cache-timing side channels.
- Argon2i walks memory in a fixed pattern, which resists side channels but gives up some resistance to attacks that trade memory for time.
- Argon2id behaves like Argon2i for the first half of its first pass and like Argon2d afterward. RFC 9106 names it the variant to use, and it is the one to pick unless there is a specific reason not to.
Three costs are tuned together: memory size (m, in KiB), the number of passes over that memory (t) and the degree of parallelism (p, the number of lanes). RFC 9106 suggests 2 GiB of memory with one pass and four lanes where hardware allows, or 64 MiB with three passes and four lanes on more constrained machines. OWASP's floor for web logins is lower, 19 MiB with two passes and one lane, because a server has to handle many logins at once. A 16-byte random salt is standard.
Reading an Argon2 hash
Libraries store Argon2 results as a self-describing string that begins like this: $argon2id$v=19$m=65536,t=3,p=4$, followed by the Base64-encoded salt and hash. Here v=19 is version 1.3 of the algorithm (0x13 in hexadecimal), m=65536 means 64 MiB of memory, t=3 means three passes and p=4 means four lanes. Because the settings travel with the hash, a system can verify old hashes and quietly upgrade them to stronger settings at the next successful login. The reference command-line tool takes the same settings, as in argon2 somesalt -id -t 3 -m 16 -p 4, where -m 16 means 2^16 KiB.
Where Argon2 is used, and its limits
Argon2id is the default in libsodium's password hashing API, LUKS2 disk encryption on Linux uses Argon2 by default to derive its unlocking keys, and password managers and many web frameworks support it. The main limitation is compliance: NIST hasn't approved Argon2, so systems that must use FIPS-validated cryptography still use PBKDF2. Memory settings also need care. A server that lets unlimited simultaneous logins each claim 2 GiB can be knocked over by a flood of login attempts, so sensible parameters and rate limiting go together.
Argon2 vs. bcrypt vs. scrypt
bcrypt works in a small, fixed 4 KB of state and accepts at most 72 bytes of input. scrypt, published in 2009, was the first widely used memory-hard function, but raising its main cost parameter raises memory and time together, which makes it harder to tune. Argon2 sets memory, time and parallelism independently and accepts long inputs. All three need a unique salt per password, and none of them makes a password from a breach list safe.
Argon2 on the CompTIA Security+ exam
SY0-801 no longer lists key stretching as a separate item, and Argon2 belongs with secure password storage, taught alongside salting and hashing algorithms under objective 1.3, the cryptographic solutions objective. Wording such as "resist GPU cracking of stolen password hashes" or "use a memory-hard password hashing algorithm" points to Argon2id. If the question stresses FIPS compliance instead, PBKDF2 is the better fit. Distractors include SHA-3 and SHA-512, which are strong but fast, and encrypting stored passwords, which is reversible.