Category: Passwords & Hashing

Argon2

Also known as: Argon2d, Argon2i, Argon2id

Simply put

Argon2 is a password-hashing algorithm designed to securely transform passwords into stored values that are difficult for attackers to reverse. It won the 2015 Password Hashing Competition and is widely recommended for protecting passwords. It is built to be memory-hard, meaning it deliberately consumes significant memory to make large-scale password-cracking attacks more expensive.

Formal definition

Argon2 is a memory-hard function used for password hashing and key derivation, selected as the winner of the 2015 Password Hashing Competition (PHC) and specified in RFC 9106. It exists in three variants: Argon2d (data-dependent memory access, offering resistance to GPU cracking but greater vulnerability to side-channel attacks), Argon2i (data-independent memory access, intended to resist side-channel attacks), and Argon2id (a hybrid combining both approaches). Argon2 is parameterized, typically taking configurable memory cost, time (iteration) cost, and parallelism (degree of parallelism) inputs that tune its resource consumption for a given deployment. Note that Argon2 addresses secure credential storage and is distinct from authentication protocols and authorization decisions; specific parameter recommendations vary by deployment and are out of scope for this definition.

Why it matters

Password databases remain a primary target for attackers, and the security of stored credentials depends heavily on how they are hashed. When a credential store is breached, the difficulty an attacker faces in recovering the original passwords is determined by the hashing algorithm and its configured cost parameters. Argon2 was selected as the winner of the 2015 Password Hashing Competition specifically because it advanced the state of the art in resisting large-scale offline cracking, and it is widely recommended for protecting passwords at rest.

Argon2's defining property is that it is memory-hard: it deliberately consumes significant memory to make password-cracking attacks more expensive. This design directly targets the economics of modern cracking, which often relies on specialized hardware such as GPUs that can compute simple hashes in massive parallel batches. By forcing each hash computation to occupy substantial memory, Argon2 reduces the advantage attackers gain from such hardware, raising the cost of brute-force and dictionary attacks against a stolen credential store.

It is important to place Argon2 correctly in an IAM architecture. Argon2 addresses secure credential storage, how a password is transformed into a stored value, and is distinct from authentication protocols and authorization decisions. It does not verify who a user is or determine what they may access; it protects the confidentiality of the secrets that later feed into an authentication step. Choosing Argon2 does not by itself constitute a complete authentication strategy.

Who it's relevant to

IAM Engineers and Identity Platform Developers

Engineers implementing credential storage need to select a password-hashing algorithm and configure its parameters. Argon2, and in particular the Argon2id hybrid variant, is a common recommendation for hashing passwords at rest. Understanding the memory, time, and parallelism cost parameters is essential to balancing cracking resistance against the performance impact on legitimate authentication flows.

Security Architects

Architects evaluating how credentials are protected should understand Argon2's memory-hard design and how the three variants map to different threat models, data-dependent (Argon2d), data-independent (Argon2i), and hybrid (Argon2id). Recognizing that Argon2 addresses credential storage, and is separate from authentication protocols and authorization decisions, helps keep responsibilities clearly delineated in the overall design.

Compliance and Audit Leads

Auditors reviewing credential-handling controls may assess whether a modern, well-regarded password-hashing function is in use. Argon2's status as the winner of the 2015 Password Hashing Competition and its specification in RFC 9106 make it a recognizable reference point, though the appropriateness of specific configured parameters depends on deployment context.

Inside Argon2

Argon2 variants

Argon2 is defined in three variants: Argon2d, which maximizes resistance to GPU cracking attacks but is more vulnerable to side-channel attacks; Argon2i, which is optimized to resist side-channel timing attacks by using data-independent memory access; and Argon2id, a hybrid that combines both approaches and is generally recommended as the default for password hashing in most deployments.

Memory-hardness

Argon2 is a memory-hard function, meaning it is designed to consume a configurable and substantial amount of memory during computation. This raises the cost of large-scale parallel attacks on specialized hardware such as GPUs and ASICs, distinguishing it from purely CPU-bound hashing schemes.

Tunable cost parameters

Argon2 exposes three primary parameters: memory cost (the amount of memory used), time cost or iterations (the number of passes over memory), and parallelism (the number of threads or lanes). These allow practitioners to tune the work factor to their hardware and threat model.

Salt and optional inputs

Argon2 takes a unique per-password salt to defend against precomputation and rainbow-table attacks, and it optionally supports a secret key (sometimes called a pepper) and associated data as additional inputs, depending on the implementation and configuration.

Role in credential storage

Argon2 is a password hashing function used to protect stored credentials at rest. It is part of the knowledge-factor verification path and is out of scope for the broader authentication decision, authorization, and session or token issuance that follow a successful credential check.

Common questions

Answers to the questions practitioners most commonly ask about Argon2.

Is Argon2 an authentication protocol or a way to authenticate users?

No. Argon2 is a password hashing function, not an authentication protocol. It is used to derive and verify a stored representation of a password credential, which is one component that may support the authentication step (verifying who a principal is). Argon2 itself does not define how a user proves identity, how sessions are established, or how tokens are issued; those concerns belong to the surrounding authentication flow and protocols.

Does hashing a password with Argon2 encrypt it?

No. Hashing and encryption are distinct operations. Argon2 produces a one-way hash from which the original password cannot be recovered, whereas encryption is reversible with the appropriate key. Storing an Argon2 hash is therefore not the same as storing an encrypted password, and Argon2 output should not be described as ciphertext.

Which Argon2 variant should typically be selected for password hashing?

Argon2 defines multiple variants, and the choice depends on the threat model and guidance you are following. In most password-storage deployments the variant designed to resist side-channel attacks while providing memory-hardness is preferred, but the correct selection should follow current authoritative guidance and your library's recommended default rather than a fixed rule. Confirm which variants your chosen implementation supports before standardizing on one.

How should Argon2 cost parameters be tuned in a deployment?

Argon2 exposes tunable parameters typically including memory usage, iteration (time) count, and degree of parallelism. These are usually calibrated against the target hardware so that verification remains acceptable for legitimate authentication load while raising the cost of large-scale offline guessing. Tuning depends on your hardware, latency budget, and concurrency, so parameters should be benchmarked in your own environment and revisited as hardware changes; treat any specific values as configuration-dependent.

Does Argon2 require a separate salt, and how is it typically handled?

Argon2 is designed to be used with a unique per-password salt, which defends against precomputation and reuse attacks across accounts. In most implementations the salt is generated per credential and stored alongside the resulting hash, often within a single encoded string that also captures the variant and parameters. Applications generally should not reuse a fixed salt across credentials; rely on your library's salt handling rather than implementing it manually where possible.

How can an existing password store be migrated to Argon2 without forcing a mass reset?

A common approach is to rehash credentials with Argon2 opportunistically at the next successful authentication, when the plaintext password is briefly available for verification. Records still using the legacy algorithm are upgraded over time as users sign in, and the stored encoding can indicate which algorithm and parameters were used so verification selects the correct path. The exact migration mechanics depend on your library's support for algorithm detection and parameter upgrades, so validate this behavior in your implementation.

Common misconceptions

Argon2 is an encryption algorithm that protects passwords so they can be recovered.

Argon2 is a one-way password hashing function, not an encryption scheme. It produces a hash intended for verification, and the original password is not designed to be recoverable from the stored output. Hashing and encryption are distinct concepts here.

Argon2id is always the correct choice and the specific variant does not matter.

The variants have different resistance profiles: Argon2d favors resistance to GPU-based cracking, Argon2i favors resistance to side-channel attacks, and Argon2id is a hybrid. Argon2id is commonly recommended as a default for password hashing, but the appropriate choice depends on the deployment context and threat model.

Choosing Argon2 alone makes stored passwords secure regardless of settings.

The security Argon2 provides depends heavily on how its memory, iteration, and parallelism parameters are configured, along with the use of a unique salt. Weak parameters can substantially reduce its resistance to attack, so the algorithm choice is necessary but not sufficient on its own.

Best practices

In most deployments, select Argon2id as the default variant unless a specific threat model justifies Argon2d or Argon2i, and document the rationale for the choice.

Use a unique, randomly generated salt for every password, and store it alongside the hash so verification remains reproducible.

Tune the memory cost, iteration count, and parallelism parameters to the highest values your hardware and latency budget can tolerate, and revisit these settings periodically as hardware capabilities change.

Consider adding a secret key or pepper as an additional input where the implementation supports it, keeping that secret managed separately from the stored hashes.

Store the algorithm identifier and parameters together with each hash so credentials can be verified consistently and rehashed transparently when parameters are upgraded.

Treat Argon2 strictly as the credential-hashing step and keep it separate from downstream authentication decisions, session management, and token issuance.