Is there a way to find out how many KDF iterations are currently being used? The settings page defaults to 100,000 instead of the current value. I can’t remember if I selected 500,000 or 1,000,000 iterations.
On another note, what’s the most iterations someone has used with an iPhone 14 Pro? Curious how high you can go before someone notice’s things slowing down.
Never mind. I have it at 1 million. I just realized there was an extra zero there. I thought it was defaulting back to 100,000.
Using iPhone 11 with max iteration of 2,000,000 and don’t see any difference between that and 100,000.
And my computer also don’t notice anything different, so as long as your devices are of a newer model, I don’t see anything wrong with making it as high as possible.
I don’t clearly understand the KDF iterations. How much more secure is it using 2,000,000 instead of 1,000,000 or 500,000?
My understanding of Iterations is not the best but I will try to explain.
Iterations is **the “work factor” for how many times your password is hash before its stored it in their database. So it will require more computing power to try to decode your password.
I really hope someone can give you a better explanation and examples. This isn’t what I got control over
Is KDF iterations applicable only to Log In and not Unlock?
I think phone apps tend to Log In only once and from then just unlocking. Therefore one wouldn’t notice any delay on a phone with high iteration count.
To mark this topic as solved, just adding the location of KDF readout:
The setting is currently viewable by visiting the web vault , tapping your profile in the top right → Account Settings → Security → Keys and labelled as KDF Algorithm.
The KDF iterations increase the cracking time linearly, so 2,000,000 will take four times as long to crack (on average) than 500,000. This is equivalent to the effect of increasing your master password entropy by 2 bits, because log2(2000000/500000) = log2(4) = 2.
In contrast, increasing the length of your master password increases the cracking time exponentially. For example adding one more diceware word to a randomly generated passphrase will make the cracking time almost 8000 times longer (7776, to be exact, if using the EFF word list), which corresponds to approximately 13 bits of additional entropy.
If using a master password that is a random string of printable ASCII characters, then adding one more character to the password will increase the average cracking time by a factor of 95 (corresponding to around 7 bits).
Thus, increasing the number of KDF iterations does make it more challenging to crack your master password, but it is nowhere near as effective as increasing the length of your master password.
Regarding your question, I believe that is correct. According to the docs PBKDF2 is the hashing algorithm used on the master password to gain the encrypted vault data locally on your device, and the account’s encryption key for your vault data.
Once logged in if you choose to only unlock, your vault data is stored encrypted locally on your device which allows for an offline cache as well. Since this is only needing to decrypt the data locally I believe you would be right that unlock would not be affected by increased PBKDF iterations past the initial log in.
I may have misunderstood, but I don’t think this is accurate. When the vault is locked, the vault data are cleared from memory, and the decryption of the locally stored vault that happens when unlocking requires the account encryption key, which is itself encrypted in the form of a “PIN protected key”. The decryption of the PIN-protected key does require stretching of the PIN by PBKDF2-HMAC-SHA256 using the specified number of KDF iterations. Thus, the performance hit, if any, should occur both when logging in and when unlocking (as well as when setting the PIN).
I believe this is the relevant code (line 41):
In addition to the work factor as already explained. I think there is a secondary benefit.
I think the iteration count will be stored in your vault but as plain text i.e. unencrypted because BW will need to read that before being able to do any decryption. In this case I suggest that in the event of a breach then hackers will attack vaults with the lowest KDF iterations first so having a high iteration will make sure your safe for longer.