How to Choose the Right Parameters for Argon2

Argon2 won the Password Hashing Competition (PHC) because it lets you dial in memory, CPU time, and parallelism independently. That flexibility is powerful, but it also raises a question: which numbers should you actually use in production?

This guide explains each Argon2 parameter, highlights the trade-offs between Argon2id, Argon2i, and Argon2d, and provides tested presets you can copy into CipherTools or your backend code.

---

Quick Reference: Recommended Presets

💡 Rule of thumb: Start from the interactive preset, measure the latency on your slowest device, then increase memory or iterations until you reach ~250 ms per hash. Attackers must pay the same cost for every guess.

---

Understanding Each Parameter

Variant (argon2id, argon2i, argon2d)

• Argon2id blends the strengths of Argon2i and Argon2d. Use it for almost every login or API token workload.
• Argon2i uses data-independent memory access, making it safer on systems where side-channel leakage (cache timing, shared hosting) is a concern.
• Argon2d is fastest and most GPU-resistant but leaks information through memory access patterns. Reserve it for situations where you control the hardware and side channels are irrelevant.

Memory Cost (m in KiB)

Memory is Argon2’s main defense: large values force attackers to allocate the same amount on their rigs.

• Expressed in Kibibytes (KiB). 64 MiB = 65,536 KiB.
• For online login systems, choose a value that keeps hashing under ~200 ms on your slowest node.
• For offline use (vault exports, backups), go higher—128 MiB or even 1 GiB—because users expect fewer derivations.

Iterations (t)

Iterations multiply the CPU work. Most deployments start between 2 and 4.

• Doubling t roughly doubles hashing time without increasing memory.
• Keep at least 2 iterations, even with high memory settings, to slow down ASIC attacks that can pipeline memory access.

Parallelism (p)

Parallel lanes let Argon2 saturate multiple cores. However, increasing p also lets attackers parallelize, so set it to the logical CPU count you allocate per hash:

• p = 1 for web backends (common case).
• p = 2 only when you have spare cores and want to keep latency low while using large memory blocks.

Hash Length

The digest length in bytes. Most systems stick with 32 bytes (256 bits). Increase it only if you need a larger symmetric key as output.

---

Picking Numbers with CipherTools

Use the Argon2 Text Hash tool or Argon2 File Hash tool to experiment:

1. Select the variant (argon2id by default).
2. Enter the memory cost in KiB (e.g., 65536 for 64 MiB).
3. Set iterations, parallelism, and hash length.
4. Choose a salt encoding. Paste a Base64 or Hex salt, or switch to UTF-8 to reuse literal strings.
5. Click Generate hash, copy the encoded $argon2…$ string, and log the parameters for your backend.

Because computation happens in your browser, you can increase memory/iteration values safely to see the latency impact before updating your production configuration.

---

Measuring Latency and Tuning Safely

1. Benchmark on multiple devices. Run the PHC argon2 CLI or libsodium’s crypto_pwhash on the slowest instance type you deploy (e.g., t3.small, Raspberry Pi, Android midrange).
2. Target 50–250 ms per hash for interactive logins. Users won’t notice a quarter-second delay, but attackers will.
3. Increase memory before iterations. Memory hits GPU/ASIC attackers harder than CPU-only tweaks.
4. Use secrets when possible. Argon2 supports an optional secret (pepper). Keep it server-side to invalidate stolen hashes even if salts leak.
5. Store everything you need to verify. Persist the PHC string (it embeds m, t, p, variant, salt, and digest). CipherTools’ encoded output is ready to save as-is.

---

Handling Legacy Migrations

Moving from bcrypt/scrypt

• Run Argon2 in “upgrade on login” mode: whenever a user successfully authenticates with the legacy hash, re-hash the password using Argon2 with your new parameters.
• Compare CPU budgets. Bcrypt often uses 4–10 ms per hash, so expect higher resource usage once you jump to 64 MiB of Argon2 memory.

Enforcing Policy Updates

• Store a target “parameter version”. When m, t, or p change, mark hashes below the threshold for rehashing.
• Use a rolling window rather than forcing immediate resets, so you don’t create a support storm.

---

Testing Checklist

• Measure per-hash latency with production hardware.
• Verify that salts are unique per credential (16 bytes minimum).
• Ensure the PHC string includes argon2id (or your chosen variant) before deployment.
• Monitor authentication throughput after rollout; watch for CPU and memory alarms.
• Document the chosen m/t/p/hashLen values so security reviews can reproduce them.

---

Conclusion

Choosing Argon2 parameters is a balancing act between security and performance. Start with Argon2id, allocate as much memory as your UX tolerance allows, add a couple of iterations, and keep parallelism low unless you have dedicated hardware. CipherTools makes the experimentation painless—tweak the sliders, observe the encoded output, and copy the final PHC string into your application once you are satisfied.

Stay disciplined about revisiting these settings as hardware gets faster. An annual review of m, t, and p is one of the easiest ways to keep your password hashing posture ahead of attackers.