Why Argon2 matters for website security
Passwords are often the gateway to user accounts and sensitive data, so the method you use to transform a plain password into a stored value matters a great deal. Argon2 is a modern password-hashing function designed to make password cracking expensive for attackers while remaining practical for normal authentication systems. It won the Password Hashing Competition in 2015 and has become a preferred choice for new systems because of its resistance to GPU and ASIC attacks through memory-hard design and flexible tuning options that let you balance security and performance.
How Argon2 works at a high level
At its core, Argon2 turns a password (plus a unique salt) into a fixed-size output through repeated, memory-intensive computation. The goal is to force any password-guessing attempt to spend both time and a substantial amount of RAM, so building specialized hardware or running massive parallel cracking operations becomes expensive. Argon2 takes a few key inputs,memory size, number of iterations (time cost), and degree of parallelism,and uses them to allocate memory blocks and mix data across those blocks in a way that prevents shortcuts. Because the computation is memory-bound, GPUs or ASICs that are optimized for raw number-crunching gain little advantage unless they also commit large amounts of fast memory.
Key parameters explained
When you configure Argon2 you work with a few explicit knobs. Memory cost determines how much RAM the algorithm uses during hashing; higher memory slows attackers who need to provision RAM for each guess. Time cost (sometimes called iterations) sets how many passes the algorithm makes, raising the CPU time per hash. Parallelism controls how many lanes of memory are processed in parallel, allowing use of multiple CPU cores. You also supply a unique salt (random per-password) and an output length for the final hash. Libraries usually encode the chosen parameters into the resulting string so you can store them alongside the hash and use the same settings when verifying passwords.
Variants: Argon2d, Argon2i, Argon2id
Argon2 comes in three variants that emphasize different threat models. Argon2d accesses memory in a data-dependent pattern, which improves resistance to GPU-based parallel cracking but has potential side-channel risks on some platforms. Argon2i uses data-independent memory access that is safer with respect to side-channel attacks like timing, which can be relevant in shared or untrusted environments. Argon2id is a hybrid: it starts with data-independent passes and finishes with data-dependent mixing, offering a balanced trade-off and is generally recommended for most server-side password hashing needs.
Practical setup and recommended configurations
There is no one-size-fits-all setting because available CPU, RAM, and user experience constraints vary. Instead, aim for a configuration that makes a single password verification take somewhere between 100 and 500 milliseconds on your authentication server while leaving headroom for peak load. A common starting point for web servers is Argon2id with memory between 64 MB and 512 MB, 2–4 iterations, and parallelism set to the number of logical cores you can safely dedicate to hashing. For lower-resource environments (mobile clients, IoT), reduce memory and iterations to preserve responsiveness; for high-security systems you can increase both.
Always use a randomly generated salt per password (16 bytes or more) and store the salt and parameters alongside the hash in your user database. Most libraries output a single encoded string that contains the variant, version, memory, time, parallelism, the base64 salt, and the base64 hash , for example:
$argon2id$v=19$m=65536,t=3,p=4$uXJz...$Yk9u...Integrating Argon2 into a website
Integration follows the familiar password-storage pattern: when a user creates or changes a password, generate a cryptographically secure random salt, run Argon2 with your chosen parameters, then store the encoded hash string (which captures the parameters and salt). When verifying a login, pass the provided password and the stored encoded hash to the library’s verify function; the library will extract parameters and salt and perform the same computation to check for a match. Choose well-maintained libraries instead of writing your own implementation: libsodium, the reference argon2 library, and language bindings (for Node.js, Python, Java, Rust, Go, etc.) are reliable choices.
Beyond hashing itself, combine Argon2 with good operational practices: enforce reasonable password complexity or use password strength meters, apply rate limiting and account lockout policies to slow brute-force attempts, and require multi-factor authentication for sensitive operations. Consider using a server-side “pepper” (a secret key stored outside the database) if you want an extra layer that requires an attacker to compromise your secret store in addition to the database to carry out offline cracking.
Comparison with other password-hashing options
Compared to PBKDF2 and bcrypt, Argon2 typically offers stronger protection against modern cracking hardware because it is memory-hard by design. PBKDF2 is CPU-bound and remains useful if hardware acceleration is not a concern, but it’s less resistant to GPUs and ASICs. bcrypt is time-tested and safe for many applications, but its internal structure and limited memory usage mean it’s not as robust as Argon2 against specialized attackers. scrypt introduced memory-hard hashing earlier and shares the same goals as Argon2; however, Argon2 has performance advantages and more flexible parameter choices in many implementations.
Security considerations and migration
If you already use bcrypt, PBKDF2, or scrypt, you can migrate to Argon2 by re-hashing passwords at login: when a user authenticates successfully with the old scheme, immediately hash the plain password again with Argon2 and store the new hash. Keep monitoring the performance and update parameters as hardware evolves. Also be mindful of side-channel risks when running Argon2i or Argon2d in environments where timing leaks or shared memory could be exploited; Argon2id is a safe default choice for general web applications. Finally, plan resource usage so that legitimate traffic cannot accidentally overload your servers when password checking is intentionally expensive.
Libraries and tools
Use well-audited libraries rather than rolling your own crypto. Popular options include libsodium (which provides high-level APIs and safe defaults), the argon2 reference library with bindings in many languages, and community packages for Node.js (argon2), Python (argon2-cffi), Java (Bouncy Castle supports Argon2), and others. Many libraries will produce the standard encoded string and certificate-ready verification functions, simplifying correct parameter handling and storage.
Summary
Argon2 is a modern, memory-hard password hashing algorithm designed to make offline password cracking expensive by requiring significant memory and CPU resources per guess. Choose Argon2id for most web applications, tune memory/time/parallelism so hashing costs are intentionally high but still reasonable for your infrastructure, use a unique salt per password, and store the encoded hash and parameters. Combine Argon2 with rate limiting, multi-factor authentication, and secure secrets handling to build a resilient authentication system.
frequently asked questions
Is Argon2 better than bcrypt or PBKDF2?
In most modern threat models, yes: Argon2 is designed to be memory-hard, which limits the advantage GPUs and ASICs have when cracking passwords. bcrypt and PBKDF2 remain safe and widely supported, but Argon2 typically provides stronger resistance to large-scale offline attacks.
Which Argon2 variant should I use?
For web servers and typical server-side storage, Argon2id is the recommended default because it balances protection against side-channel leaks and GPU-optimized cracking. Use Argon2i when you need maximum side-channel resistance in constrained or shared environments, and use Argon2d only when you specifically want the data-dependent mixing and understand the side-channel implications.
What parameter values should I pick?
There are no universal numbers, but aim for a single verify operation to take around 100–500 milliseconds on your authentication hardware. Common starting points are Argon2id with 64–256 MB memory, 2–4 iterations, and parallelism matching a safe number of CPU cores. Benchmark on your infrastructure and increase parameters if you have spare resources and need higher resistance to cracking.
Do I need to rotate or re-hash stored passwords?
Rotate hashes when you change algorithms or increase parameters. A common strategy is to re-hash the password with the new settings at the next successful login. If an immediate migration is required, force a password reset or re-enrollment with the new hashing scheme.
Can Argon2 protect against all password attacks?
No single tool covers every risk. Argon2 makes offline cracking much harder, but it doesn’t prevent phishing, weak passwords, database leaks, or stolen salts if your storage is compromised. Use Argon2 as part of a layered approach: enforce good password policies, enable multi-factor authentication, secure your servers and databases, and monitor for suspicious activity.
