So just FUD? An entire article for saying that they should increase the default number of interactions?
You can do better if you have to do FUD.
Bitwarden design flaw: Server side iterations
91–100 of 264 posts
Re: Bitwarden design flaw: Server side iterations
#92I still haven't seen a clear explanation of how the # of iterations scales in relation to password length. If it is true a few extra characters is as good as having sky-high iterations, the guidance should be on 'forcing' users choose long-enough passwords, not in this nitpicking over the 'right' # of iterations.
The number of iterations scales linearly with the cost of brute-forcing. The cost scales exponentially with the length of the password, assuming a random password (stops scaling when you reach the hash size I think). Both are important because you can't freely increase the password length, they become more annoying to enter and remember.
What alphanumeric password length would be sufficient enough to still be protected with only 1000 or 5000 iterations?
Re: Bitwarden design flaw: Server side iterations
#93Tangentially related: why would a password manager provide a configurable iteration count? This is a number whose purpose is fairly hard to understand for many people and yet it’s an important corner stone for password security, especially for those who do not grasp the concept of an iteration count. This should absolutely be application managed and gradually increased over time. Also: while I understand that FIPS is…
> This should absolutely be application managed and gradually increased over time. One issue I could see with that is that because it’s the encryption key it’s going to lock out all your “live” devices, so an explicit step is an easy opportunity to warn them. The second issue is that the transcryption would have to be done on login, which is a pretty shit UX as the user logs in then immediately gets locked out for ho…
> One issue I could see with that is that because it’s the encryption key it’s going to lock out all your “live” devices, so an explicit step is an easy opportunity to warn them.
how so? The iteration count must be part of the non-encrypted parts of the vault data. If a client is offline, it will use its locally stored vault with the old (lower) iteration count. If it's online, it will have the updated vault with the higher iteration count.
> The second issue is that the transcryption would have to be done on login, which is a pretty shit UX as the user logs in then immediately gets locked out for however long it takes to convert the store (then again for most people I’d assume the payload is not enormous).
You could do this asynchronously in the background: Decrypt the vault, store it in memory (which all password managers do for some amount of time in order to provide any UI), re-encrypt, store to disk, send blob (which will continue an unencrypted iteration count) to server.
But this is the complicated case where the vault is re-keyed. What would totally be sufficient is to re-encrypt the same value key using a new hash derived from the same password, only with more rounds which means that the bulk of the vault blob won't change - only the password-derived key and the iteration count.
If any of this happens simultaneously on multiple machines, treat it the same way as you already treat editing conflicts (I'm not offering guidance there - this is a hard problem that each cloud provider is already solving one way or another).
> They are but needing to update the work factor as hardware progresses remains. In fact scrypt and argon have more work factor knobs than pbkdf2, which only has the iterations count.
Given the current state of the art and given these two algorithms, I think it would need to happen significantly less often than with PBKDF2, so if there's something that would need to cause the UI to re-lock immediately after unlock as you think (and I'm not sure about) then having argon or scrypt in the loop means you have more time between causes of shitty UX.
Re: Bitwarden design flaw: Server side iterations
#94Tangentially related: why would a password manager provide a configurable iteration count? This is a number whose purpose is fairly hard to understand for many people and yet it’s an important corner stone for password security, especially for those who do not grasp the concept of an iteration count. This should absolutely be application managed and gradually increased over time. Also: while I understand that FIPS is…
keepassxc does this the right way — you're not picking the "iteration count" (which is hard enough to understand even for someone relatively technically inclined), but the time it takes to open the database. The default is 1 second, with the minimum of 100 ms.
"Higher values offer more protection, but opening the database will take longer".
I highly recommend keepassxc to everyone instead of these password-solutions-of-the-day that are coming and going so fast it's hard to remember all of them.
Re: Bitwarden design flaw: Server side iterations
#95Earlier quoted context omitted.
Have you seen 1Passwords security design? I am not an expert, but wanted to hear from someone is.
It is not opensource, therefore you cannot self-host it, therefore you depend on a thirdparty.
Can one depend on a third party if it's end-to-end encrypted?
Re: Bitwarden design flaw: Server side iterations
#96Earlier quoted context omitted.
What about offline only managers?
Is it stored on a device which connects to the Internet? It's online! I think there's a role to play for things like KeePass when you need to share some secret values with family or team members, but it shouldn't be for high security things. Two-factor authentication is probably our best practical defense right now, and generally the best way to do that is not to have your password saved anywhere: Two-factor is "some…
Ehhhh, I dunno on that one. I think "stored on an end user device" is quite different from "stored on a server with a public address". Firewall rules differ, for one. ISPs are more restrictive on what they flag as suspicious for domestic connections for two.
Yes it would be better if the password manager were airgapped but that's a bad trade off in terms of user inefficiency and risk reduction IMO. In the same way, the reduction of attack surface by using post-its seems dulled by the consequent decrease in password complexity caused by people deciding their own passwords (since people subconsciously apply patterns to "random" strings they generate).
This isn't to say "post its are bad" or "password managers good" but I am pushing back at the categorical statement of "post its good, managers bad". It seems contingent on risk profile.
Re: Bitwarden design flaw: Server side iterations
#97Earlier quoted context omitted.
Can someone Eli5 iterations in this context?
Your master password is put in a box that’s very hard to break into. But because someone might be really determined to get in, we put that box in another box that’s just as hard to break into. And because someone might be really really determined, we keep putting those boxes in new boxes so it’s really really difficult to get to the password. But sometimes we also need to get to the password, so we use enough boxes t…
That's good, I like the box in box imagery.
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 =)
Re: Bitwarden design flaw: Server side iterations
#98is apple keychain safer than all these 3rd party options now?...
Re: Bitwarden design flaw: Server side iterations
#99Tangentially related: why would a password manager provide a configurable iteration count? This is a number whose purpose is fairly hard to understand for many people and yet it’s an important corner stone for password security, especially for those who do not grasp the concept of an iteration count. This should absolutely be application managed and gradually increased over time. Also: while I understand that FIPS is…
Or why would it have internet facing data ? At some point maybe we can just transfer stuff around ourselves especially the list of all our passwords ?
I have 524 passwords in my vault. That's a list large enough to require a big sheet of paper that's very inconvenient to carry around. I'm also changing passwords often enough such that keeping track of which password I changed on what machine in order to just carry deltas with me and updating my hand-written lists manually is way too inconvenient.
Syncing password managers solve all these issues and, if they do encryption right, there is nothing that could possibly happen even if they are hacked and an attacker gains access to my encrypted data.
The doing it right part is why I was asking my questions with regards to PBKDF2.
Re: Bitwarden design flaw: Server side iterations
#100Tangentially related: why would a password manager provide a configurable iteration count? This is a number whose purpose is fairly hard to understand for many people and yet it’s an important corner stone for password security, especially for those who do not grasp the concept of an iteration count. This should absolutely be application managed and gradually increased over time. Also: while I understand that FIPS is…
One issue with "gradually increasing over time" is that, without a master password change, the old hashes are still "out there" and potentially available for inspection.