We're sorry but this app doesn't work properly without JavaScript enabled. Please enable it to continue.

This lesson's interactive features are locked, please to keep using them

Argon2 Parameters

Using Argon2id is great, but its "cost" parameters determine how expensive each password guess actually is, and you need to get them right:

  • Memory cost (m) is the amount of memory used by one hash, measured in KiB by the Node argon2 package.
  • Time cost (t) is the number of passes over that memory.
  • Parallelism (p) is the number of computational lanes.

Higher costs make offline cracking more expensive, but they also consume more resources on your login server. A password policy that's too cheap helps attackers. One that's too expensive can turn a burst of login attempts into a denial-of-service problem.

Define One Policy

Here's an explicit Argon2id policy based on the minimum configuration in the current OWASP Password Storage Cheat Sheet:

const PASSWORD_HASH_OPTIONS = {
  type: argon2.argon2id,
  memoryCost: 19 * 1024,
  timeCost: 2,
  parallelism: 1,
} as const;

That's 19 MiB of memory, two iterations, and one degree of parallelism. Real systems should benchmark their authentication workload and choose the strongest policy their hardware and availability requirements can safely support.

Parameters Travel With the Hash

An encoded Argon2id hash records the parameters that created it. Verification reads those stored values, so changing the current policy won't make older hashes unreadable... thank goodness.

There's even a handy argon2.needsRehash helper that compares a stored hash's parameters with the current policy:

if (argon2.needsRehash(passwordHash, PASSWORD_HASH_OPTIONS)) {
  // Hash the already-verified password with the current policy.
}

The best time to upgrade is immediately after successful verification, while the application already has the plaintext password.

Assignment

Bearly Secure repeats its Argon2id options and never upgrades old hashes. Centralize the password-hashing policy and upgrade legacy or stale hashes when a password is successfully verified during login or MFA recovery.

Run and submit the CLI tests from the project root.