Archivehashing
Choosing Argon2 Parameters
Memory, iterations, and parallelism are a budget, not a magic tuple — here is how to spend it.
- Published
- Reading time
- 1 min read
Argon2id has three knobs: memory cost m (KiB), time cost t (iterations), and parallelism p. The goal is to make one guess expensive in both time and memory, because GPUs and ASICs are cheap in time but poor in per-core memory bandwidth.
A sane starting point
m = 64 MiB(65536 KiB)t = 3p = 1per hash, scaling with cores only if you must- Tune so a single hash takes 100–500 ms on your production hardware.
Measure under load, not on your laptop. If login latency budget is 200 ms and the hash takes 400 ms, lower memory before lowering iterations — dropping t to 1 is a much bigger security loss than halving m.
Practical details
- Cap concurrent hashing. 64 MiB × 500 concurrent logins is 32 GiB of transient allocation; that is a denial-of-service vector.
- Store the parameters and the salt in the hash string (
$argon2id$v=19$m=65536,t=3,p=1$...), so you can rehash on next login when you upgrade. - Do not add your own pepper into the salt field — keep them separate.
Takeaway: pick memory first, then iterations, then verify under real concurrency. Parameters that ignore your login concurrency are a load test waiting to happen.