Why use Argon2 for password hashing
Argon2 is the current proven choice for password hashing because it was built specifically to resist GPU and ASIC accelerated attacks by consuming both memory and CPU time. Using a modern password-hashing function reduces the chance that leaked password databases can be brute-forced quickly, and Argon2 gives you explicit knobs , memory, time (iterations), and parallelism , to tune that trade-off. For most web and application use-cases, choosing the right variant and parameters, then implementing secure salt handling and storage, is what determines real-world safety more than the choice of a library.
<h2>Key parameters explained</h2>
<h3>Variant</h3>
<p>
Argon2 comes in three main variants: Argon2d, Argon2i, and Argon2id. Argon2d is optimized for resistance to GPU cracking but accesses memory in a data-dependent way, which can be risky if you need side-channel resistance. Argon2i is data-independent and safer against side-channel leaks but slightly less GPU-resistant. Argon2id combines both approaches and is the recommended default for most password hashing tasks because it balances GPU resistance with side-channel protection.
</p>
<h3>Memory (RAM)</h3>
<p>
Memory is the primary defense against parallelized hardware attacks. It is typically measured in kibibytes (KiB). Increasing memory forces attackers to use proportionally more RAM per parallel guess, which raises cost. For interactive login systems, a common starting point is tens of megabytes (for example 64 MiB = 65536 KiB), but the exact value should be set by testing on your deployment hardware. The right choice maximizes the memory you can afford while keeping authentication latency acceptable.
</p>
<h3>Time cost (iterations)</h3>
<p>
Time cost controls the number of internal iterations the algorithm performs. Increasing this makes each hash slower and more expensive for attackers. Combine time cost with memory to hit an acceptable latency target. Typical values range from 1 to 4 for many deployments, but again measure and tune to a target response time (often 100–500 ms for interactive logins).
</p>
<h3>Parallelism (threads)</h3>
<p>
Parallelism specifies how many lanes the algorithm uses internally; it maps to CPU parallelism. On servers with many cores you might increase this value to use available hardware, but do not exceed the number of hardware threads available to the process, and avoid high values for single-threaded environments where it could introduce contention.
</p>
<h3>Salt and output length</h3>
<p>
Always use a cryptographically secure random salt for each password. A salt length of 16 bytes is typical. Output (hash) length is usually 16–32 bytes depending on your verification scheme. The canonical encoded Argon2 string already contains the parameters and salt encoded, which makes verification and parameter upgrades easier.
</p>
<h2>Step-by-step configuration</h2>
<p>
Below is a practical step sequence you can follow to configure Argon2 securely and adaptably. The sequence places emphasis on testing and storing parameters alongside the hash so future changes are manageable.
</p>
<h3>Step 1 , Choose the variant</h3>
<p>
For most applications pick Argon2id. It gives good resistance to parallel hardware attacks and reasonable protection against side-channel leaks. Only consider Argon2i if your threat model prioritizes side-channel safety in constrained environments, and use Argon2d only for specialized cases where you fully understand the trade-offs.
</p>
<h3>Step 2 , Establish an acceptable hashing latency</h3>
<p>
Decide how much time you can tolerate for a login operation , a common target is 100–500 ms on your slowest authentication server under normal load. This is a user-experience and capacity decision: slower hashing increases security but requires more CPU for the same throughput. Measure latency on representative hardware and under realistic concurrency.
</p>
<h3>Step 3 , Benchmark memory and time settings</h3>
<p>
Start with a conservative configuration (for example Argon2id with memory 64 MiB, time cost 2, parallelism 1, hash length 32) and then run benchmarks. Increase memory or time until you reach your latency target. For example, on one machine you might find memory 64 MiB and time 3 gives 200 ms, whereas on a low-powered vps you may need to lower memory or time. Record the chosen parameters so you can reproduce them for all servers.
</p>
<h3>Step 4 , Implement secure salt generation</h3>
<p>
Generate a unique random salt per password using a CSPRNG. Use at least 16 bytes. Many Argon2 libraries handle salt generation for you if you call a high-level API, but if you generate salts yourself, use the platform's secure random function (e.g., os.urandom in Python, crypto.randomBytes in Node, crypto/rand in Go).
</p>
<h3>Step 5 , Use a well-maintained library and store encoded hashes</h3>
<p>
Prefer established libraries rather than reimplementing hashing. Store the full encoded string the library returns , it typically looks like:
</p>
<pre><code>$argon2id$v=19$m=65536,t=3,p=4$base64(salt)$base64(hash)</code></pre>
<p>
That encoded string includes the variant, version, memory, time, parallelism, salt, and hash. Keeping that string in your database makes verification straightforward and preserves the original parameters for future upgrades.
</p>
<h3>Step 6 , Verification and upgrades</h3>
<p>
When verifying a password, parse the encoded string and call the library's verify function. If you later want stronger parameters, implement a rehash-on-login strategy: when a user successfully logs in, detect that the stored parameters are weaker than current policy and re-hash the password with the new parameters and save the new encoded hash.
</p>
<h3>Step 7 , Consider peppering and rate limits</h3>
<p>
A pepper is a server-side secret added to the password before hashing; it protects against database leaks when the attacker lacks this secret. Use a pepper carefully: store it in a separate secure location (HSM or environment secret) and make sure your backup and rotation plans preserve access. Combine strengthening with account rate limiting, multi-factor authentication, and secure password policies , hashing alone is not a complete defense.
</p>
<h2>Quick implementation examples</h2>
<p>
The following examples show how to configure Argon2 in common languages. These snippets assume you already selected parameters from the benchmarking step and show typical API usage and verification patterns.
</p>
<h3>Python (argon2-cffi)</h3>
<pre><code>from argon2 import PasswordHasherph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4, hash_len=32, salt_len=16)
hash = ph.hash(“correct horse battery staple”)
ph.verify(hash, “correct horse battery staple”)
<h3>Node.js (argon2)</h3>
<pre><code>const argon2 = require('argon2');const options = {
type: argon2.argon2id,
memoryCost: 2 ** 16, // 65536 KiB = 64 MiB
timeCost: 3,
parallelism: 4,
hashLength: 32
};
const hash = await argon2.hash(“correct horse battery staple”, options);
// Store hash. To verify:
await argon2.verify(hash, “correct horse battery staple”);
<h3>Go (golang.org/x/crypto/argon2)</h3>
<pre><code>import (“crypto/rand”
“encoding/base64”
“golang.org/x/crypto/argon2”
)
salt := make([]byte, 16)
rand.Read(salt)
hash := argon2.IDKey([]byte(“correct horse battery staple”), salt, 3, 64*1024, 4, 32)
encodedSalt := base64.RawStdEncoding.EncodeToString(salt)
encodedHash := base64.RawStdEncoding.EncodeToString(hash)
// Store encodedSalt and encodedHash, plus the parameters used
<h2>Practical tuning checklist</h2>
<ul>
<li>Target an acceptable login latency (measure on production-like hardware).</li>
<li>Pick Argon2id unless your threat model requires otherwise.</li>
<li>Use at least 16 bytes of salt; prefer library-provided salt generation.</li>
<li>Store the encoded hash string or store parameters with the hash so verification and upgrades are simple.</li>
<li>Implement rehashing on successful login when policy changes.</li>
<li>Combine with rate limiting, MFA, and secure secret handling for peppers.</li>
</ul>
<h2>Summary</h2>
<p>
Configuring Argon2 is a process of choosing a safe variant, selecting memory/time/parallelism values that create acceptable latency on your hardware, using secure salts, and storing encoding that preserves parameters for verification and future upgrades. Begin with Argon2id, benchmark to reach a target response time, use reputable libraries to hash and verify, and plan for rehashing when you raise parameters. A careful, measured approach gives strong protection against modern cracking attempts while keeping authentication usable.
</p>
<h2>FAQs</h2>
<h3>Which Argon2 variant should I use?</h3>
<p>
Use Argon2id for most password hashing needs. It provides a balance of resistance to GPU attacks and side-channel protection. Choose Argon2i only when you specifically need data-independent memory access behavior.
</p>
<h3>How do I choose memory and time settings?</h3>
<p>
Decide an acceptable authentication latency for your users and infrastructure, then benchmark different memory and time values until hashing falls within that range. Prefer higher memory as it increases attacker cost more effectively, but do not exceed what your servers can handle concurrently.
</p>
<h3>How should I store Argon2 hashes?</h3>
<p>
Store the full encoded hash string produced by the library whenever possible. It contains the variant, version, memory, time, parallelism, salt, and hash, so verification and parameter upgrades become trivial.
</p>
<h3>Do I need a pepper in addition to salt?</h3>
<p>
A pepper is optional and provides extra protection if your database is breached but the server secret remains secure. If you use a pepper, keep it in a separate, secure location (secret manager or HSM) and plan for rotation and backup.
</p>
<h3>What about migrating existing bcrypt or PBKDF2 hashes?</h3>
<p>
Use a rehash-on-login strategy: when a user authenticates successfully with the old scheme, re-hash the plaintext password with Argon2 and replace the stored hash. This avoids forcing a bulk reset while gradually upgrading accounts.
</p>
