Bitwarden KDF key iteration number

  • Release Candidate 6
    Guest:
    We are at a “proposed final” true release candidate with nothing known remaining to be changed or fixed. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.

Adam-F

Active member
Sep 25, 2020
32
2
UK
Hi All,

Please can you provide the ideal KDF iteration for the KDF key in bitwarden at the minute it set to the default number of iterations?

Thanks

Adam
 
The defaults are fine. You should NOT be relying on KDF for baseline security. It can not make a poor password secure, it can only provide delay.
 
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) =​
8Start with twice core count
Memory (m) =​
512 (MB)Second, increase until 0.5s to 3s delay or practical limit
Iterations (i) =​
42 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]
 
Last edited: