There is no ideal setting, but so long as the password derivation takes longer than 0.5 second and less than 3-5 seconds on most devices, then it's fine. I accept about 2 seconds of delay as normal. BitWarden's defaults are good enough, but you can easily double their iterations and memory figures without consequence.
It's difficult to accurately measure BitWarden's KDF performance, but you'll know if it's taking too long to unlock your database when you log in. I use KeePass and find settings similar to those below to be acceptable. Key derivation with these settings averages 1.2 seconds on a 2013 Lenovo laptop and about 6 seconds on a Pixel 3a. I use the laptop for 99% of login activities and the phone serves only as an emergency device where I don't care about the longer delay:
Algorithm = | Argon2id | |
Parallelism (p) = | 8 | Start with twice core count |
Memory (m) = | 512 (MB) | Second, increase until 0.5s to 3s delay or practical limit |
Iterations (i) = | 4 | 2 or increase until 0.5s to 3s delay after setting Memory |
Note: The "m" setting is actually entered in bytes, but many user interfaces use MB, so double-check when changing the setting.
If your hardware is newer, you might try doubling these, but not having enough free memory will dramatically slow derivation and perhaps make a device unresponsive. There are limits to how much free memory is reliably available and anything above a few MB is going to be costly to attackers, so there's no need to go overboard. The point here is that while Iterations have been the primary work factor with traditional KDFs and hundreds of thousands might be needed, Memory is the primary factor with Argon2 and far fewer Iterations should be necessary.
Interestingly, Steve misinterpreted the Parallelism requirement when designing EnScrypt for use with SQRL and argued that "1" was best as it didn't "allow" attackers to use multiple cores. However, Parallelism is like the other settings; it
increases the resource requirements by
requiring parallel threads.
Yes, increasing Parallelism does speed up the derivation so long as free cores are available for splitting up the work, but it still increases attack cost as you first
require parallel calculations and then adjust the other settings to achieve the desired delay. In other words,
fully using your cores allows the required KDF workload to be increased with no corresponding decrease in user convenience.
Restricting to just 1 thread is not a limitation to attackers as they can simply run as many independent processes as they have CPU cores in order to parallelize their attacks; we
want to require more work so long as it doesn't cost us more time as users. In this way, SQRL could have used multiple threads to obtain the same amount of KDF work in perhaps 2 seconds as it does with a single thread in 5 seconds. We use Parallelism to help
ourselves, not our attackers, for they can always run as many parallel attacks as they can afford.
While using all available cores greatly improves work per second, requesting more Argon2 threads than existing cores has no noticeable impact on delay time in my testing, so I set Parallelism to 8 and forget it. That's the maximum allowed by KeePass, but BitWarden allows up to 16.
While I think it's valuable to understand the principles, Paul is correct that we shouldn't obsess over KDF settings. Adding 1 extra ASCII character to your password is equivalent to multiplying its KDF work requirement by 95 times. If we choose 14 chars and 1 second as a reasonable baseline strength, the configurations below are
equivalent in terms of brute force resistance (attack cost):
Random ASCII characters | KDF Delay |
|---|
15 | 0.01sec |
14 | 1sec |
13 | 1min 35sec |
12 | 2hr 30min |
This assumes that the KDF scales
linearly; that its efficiency can't be improved. Memory-hard algorithms are designed to enforce this scaling, but any KDF might become accelerable if unknown optimizations are discovered. Thus, we never want to depend upon a KDF in place of password entropy; default KDF settings are fine, even though some users will inevitably claim otherwise.
KDF delays longer than a few seconds reduce user convenience without adding relevant protection. Folks that intentionally target a 5+ second KDF delay are seeking a
feeling of security where the long wait provides hollow comfort similar to a security blanket or teddy bear. That wasted time could instead be used to memorize and type more random password characters. I have my own forgettable acronym for this: IATPS or
It's Always The Password, Stupid.
[2023-03-30 Edit: updated to more accurately reflect recommendations from Argon2 team]
