Those first 5000 iterations added over 12 bits of entropy.
The article is complaining about not adding an extra 100,000 iterations which would double the difficulty, so he's effectively berating them over 1 bit of entropy.
iirc locking with BW doesn’t do what one might expect wrt encryption state.
A good reminder to also have printed (or something) OTPs accessible in a safe place in case you need them.
That might be a little too much “like I’m 5”, but that’s the general idea. Hashing is easy one way but it still requires compute cycles to do each iteration. We don’t want to make it excessively expensive for us.
You're trying to keep something safe and all you've got is a weirdly infinite collection of cardboard boxes. So you have this brilliant idea... you get a dozen boxes and put your treasure in one of them.
That's great, it's certainly safer than leaving it laying out. It'll take someone at least like... a minute to go check all dozen boxes and find your treasure. But it still only takes you mere seconds because you know which box to open.
Except you'd really rather your treasure stay safe for longer than a minute. So you take all your boxes and put them inside other boxes. And put those boxes inside other boxes like nesting dolls. You nest each one a dozen times.
So now if someone wants to come and find your treasure, they need to open all 144 boxes to find it! But you still only need to open 12 because you know which stack to look in.
The iteration count is basically just how deeply you plan to nest your boxes.
In more concrete terms, increasing the iteration count is just a knob to control how much cpu/memory resources it takes to compute a hash. You want to turn it up enough to make brute forcing prohibitively expensive (make it as high as you can), but not so much that calculating the single correct hash to verify is too expensive (don't make it too high or else it will take too long to check your password at sign-in). People are saying this should go up over time because computing resources generally become more readily available (faster/cheaper), making both brute forcing easier as well as allowing you to perform more iterations to compute the correct hash on commodity hardware without it taking unusably long.
Put differently: with x^y nested boxes, you only have to open y. The attacker has to open x^y.
While they made it confusing by using "12" for two different things, their analogy is completely correct.
Instead of each password/location having one box, it has a box within a box within a box[...]. You have to unwrap the entire stack to check if the treasure is there.
If you use an iteration count of 5000, then when you log in you unfortunately have to do 5000 hashes. But an attacker has to do 5000 hashes per password guess.
So a deep iteration count can't substitute for a good password, but it can make up for an extra few characters. And it's basically free to increase iterations until the wait becomes visible.
So basically, I would set it at around half of the 144: 72 or did I get something wrong there?
PBKDF2 directly might be some sort of multiverse locked box? Store a "safe key" in a box, in a box, in a box, in a box, in a box... in an iteration of boxes.
Every key in the universe is able open the first box, and every other box. But each key opens up a different multiverse of boxes. The problem for the attacker is they have to open every box, in a box, in a box... in succession to get to a "safe key" stored in that multiverse, which looks like a safe key and quacks like a safe key, but might not be the right safe key.
Maybe not quite right, as the "safe key" is really just another box in the end, but that doesn't make much sense... unlike a box of multiverse of boxes =)
With plain derivation, the map takes you directly from the password to the key. With an extra iteration, the map just points to a place on the map where a trail starts.
If you want to guess the key, by guessing the password - now you have to first walk to were the password points on the map, then follow the path (the iterations) - then dig and see if the key is there. Then you can try the key in the chest (the encrypted data).
The iterations (length of path) adds a certain, predictable, amount of work in order to find the key. It does not make it harder to guess the password, just harder to get the key from the password - and so it makes it harder to check if you've guessed the right password (try the key in the lock) - because there's extra work to be done.
Now you could compare memory-hard paths and compute-hard paths by adding elevation and distance to the analogy (different types of hard work).
> Making changes in a session with a “stale” encryption key will cause data corruption that will make your data unrecoverable.
https://community.bitwarden.com/t/increasing-kdf-interations...
https://news.ycombinator.com/item?id=34152181
EDIT: Look below, this actually applies to changing master password.
This is incorrect.
https://bitwarden.com/help/what-encryption-is-used/#changing...
> When you change the iteration count, you'll be logged out of all clients. Though the risk involved in rotating your encryption key does not exist when changing KDF iteration count, we still recommend exporting your vault beforehand.
From what I read, changing the number of iterations is safe to do.
[1] 28 characters in a single case, 23 characters if both upper and lower case are used, 22 characters if you include numbers, 12 words if you use a word list of 2000 words and sample uniformly
I don't think that is practical for most users - 12 words (or 10 taken from a 10k list) - or 22 random alphanumeric characters - is hard to remember - and long enough that they are difficult to type correctly. 70 bits might be a more sensible goal - but still long. (6/7 words, 12 characters from a set of 62).
This is the "trust anchor", so something the user needs to remember and type in - from what I've seen - remembering/representing and inputting 128 random bits is tricky.
And with modest stretching and a salt, probably overkill anyway.
As for 70 bits password, it might be enough, but you need a lot of iterations (2^58) if you want to completely make up for the lost security margin. Which will also be unusably slow in practice.
When I see that I read: "With our knowledge of security and encryption, which by the way is much greater than yours, we consider that 100,000 is a perfectly safe number and a good middle point so go ahead and use it".
Am I wrong to think like that? My Master password is a battery-horse-staple thing, but not with 12 words as some other commenter says; that's absurdly long and would be too difficult for me to remember. I usually strive for around 18-20 characters, that's already in the verge of me forgetting it. I use incorrect or derived words of my own (so not really existing in dictionaries).
[1] https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
(I'm not a security expert, so I'm going by the article)
When you do this reset and sign back into your devices/browser plugins, you will need to go into the Bitwarden Settings on each one and set a few options again - notably timeout (defaults back to Browser Restart, change back to a time you're comfortable with), Biometric Unlock and PIN. All of those are local settings to each Bitwarden client/endpoint, so you need to do them on each device.
I've updated it to 600,000 iterations and so far don't see any noticeable impact on performance, both on desktop (using the Firefox extension) and on mobile (iOS).