

0 / 2 embers
0 / 3000 xp
click for more info
Complete a lesson to start your streak
click for more info
Still calibrating
click for more info
Not enough gems
Cost: 6 gems
1: Encrypting Data at Rest
incomplete
2: Key Management and Rotation
incomplete
3: Password KDFs
incomplete
4: Salts
incomplete
5: Argon2 Parameters
incomplete
6: Encrypted Files
incomplete
7: Secure Database Practices
incomplete
8: Personally Identifiable Information
incomplete
9: Financial Data
incomplete
Back
ctrl+,
Next
ctrl+.
This lesson's interactive features are locked, please to keep using them
Using Argon2id is great, but its "cost" parameters determine how expensive each password guess actually is, and you need to get them right:
m) is the amount of memory used by one hash, measured in KiB by the Node argon2 package.t) is the number of passes over that memory.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.
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.
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.
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.