These audits are reassuring, but I'm hoping someone can speak to a question I have...
I know that encryption primitives are almost never the breaking point in systems like this, but I wonder in situations like this where breaches would allow adversaries to attempt offline attacks whether they are particularly pertinent.
Specifically, while the number of iterations on the PBKDF2 SHA-256 function are high (100,001 on the client), PBKDF2 always felt to me like a footgun when compared to scrypt or argon2 which don't have as many (any?) insecure modes of operation.
The website states that AES is used, but is it in an authenticated mode (e.g. GCM ?)
Finally, their website states that they use "popular and reputable crypto libraries" and that they don't roll their own crypto, but the libraries they use are awfully low-level. Something like libsodium or FilSottile's age would be something I'd be more comfortable with when considering a hosted method.
In the meantime, I think I'll keep using KeePass2 (w/ Argon2 and ChaCha20) and synch'd with SyncThing to minimise my attack surface.
I don't see PBKDF2 as a full footgun, but maybe as the minimally still-acceptable method. When I was building my system for E2E messaging (pritact.com) I started out with PBKDF2 but kept mentally revisiting the iteration count before biting the bullet and switching to Argon2.
PBKDF stretching is a mitigation against bad passwords. The difference between PBKDF2 and argon2id is marginal because you'd need to have chosen a password that's in a narrow window between "So bad that PBKDF2 doesn't save you" while "Not so bad that argon2id can't save you either".
Stretching isn't magic. If your password is 'jszymborski' then no practical KDF will prevent bad guys just guessing "Um, maybe it's just jszymborski?" and getting in. And on the other hand if it's two dozen random alphanumerics you can use SHA256() as your KDF and be absolutely fine.
Because their users will (even if told emphatically not to) use bad passwords, Bitwarden needs a PBKDF with stretching here to buy those people more margin, but nit-picking the choice of PBKDF is missing the wood for the trees. As an end user the right thing to do regardless is use good passwords, which of course is how we got here...
PBKDF is (at best) a sub-optimal choice: their entire business model is zero-knowledge storage of cryptographic secrets. They really need to switch to Argon2 and some sort of PAKE protocol.
However, they need a cross platform solution that integrates with .NET and will also work on a budget smartphone. I've sketched out such an architecture, but I lack the time and budget to do it.
I know that encryption primitives are almost never the breaking point in systems like this, but I wonder in situations like this where breaches would allow adversaries to attempt offline attacks whether they are particularly pertinent.
Specifically, while the number of iterations on the PBKDF2 SHA-256 function are high (100,001 on the client), PBKDF2 always felt to me like a footgun when compared to scrypt or argon2 which don't have as many (any?) insecure modes of operation.
The website states that AES is used, but is it in an authenticated mode (e.g. GCM ?)
Finally, their website states that they use "popular and reputable crypto libraries" and that they don't roll their own crypto, but the libraries they use are awfully low-level. Something like libsodium or FilSottile's age would be something I'd be more comfortable with when considering a hosted method.
In the meantime, I think I'll keep using KeePass2 (w/ Argon2 and ChaCha20) and synch'd with SyncThing to minimise my attack surface.