Bitwarden KDF key iteration number

  • SpinRite v6.1 Release #3
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


Active member
Sep 25, 2020
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?


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 =​
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
1min 35sec​
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: