51–60 of 284 posts
The moral of the story here seems to be: if you want convenience you'll compromise your security. This is not exclusive to BW. Or if you want a moral of the story specific to the article: Don't use the PIN feature in BW. And perhaps, instead of a PIN use a physical key (e.g., YubiKey).
Earlier quoted context omitted.
It's a choice on the user to weaken the encryption. I don't use Bitwarden, but if they communicate that properly to the user, it's a valid compromise for convenience-versus-security.
This doesn't answer the question. Why is there a choice to encrypt something when it's completely unnecessary (according to their threat model)? No point in building unnecessary complexity into software, especially software meant for security.
FWIW on a GPU using SHA1 or SHA256 this is not very much time-protection.
The author mentions this finding was marked as out-of-scope when they reported it to Bitwarden. A couple of categories that are considered out-of-scope are listed, namely: attacks requiring physical access to a user's device, and "other side of airtight hatchway"[0] type issues. The latter seems reasonable, if the assumption is that the device is fully compromised, and ongoing surreptitious monitoring of user activit…
A PIN is a de-facto very weak password. Of course it can be brute forced!
So forget what you know about ATM PINs; this is a markedly different concept.
The PIN is still potentially useful in that it prevents anyone with access to the device from getting access to the secret information without having to perform an overt act. The difference between leaving a piece of paper with the passwords laying about and locking it in a drawer.
Earlier quoted context omitted.
A PIN is a de-facto very weak password. Of course it can be brute forced!
Indeed, which is why Bitwarden should disallow pin-only access for offline vault data altogether. Admittedly, I'm valuing a safe interface for users much more highly than one that is convenient or ergonomic.
Earlier quoted context omitted.
If you limit number of attempts, can it still be brute forced?
How can you enforce a limit when the decryption is done client side?
> Now, granted, the key derivation function is PBKDF2 with 100000 iterations FWIW on a GPU using SHA1 or SHA256 this is not very much time-protection.