> This means that you need a strong master password. And the only real way to get there is generating your password randomly.
Hm but how will I remember that? Maybe I’ll use a different password manager… :)
Bitwarden design flaw: Server side iterations
141–150 of 264 posts
Re: Bitwarden design flaw: Server side iterations
#142Earlier quoted context omitted.
I still think it's maddening that LastPass's website says that the vault is encrypted, yet in reality that wasn't and may still not be the case, where aspects of the vault as we now know aren't encrypted. Unless I'm missing something, to me that is one of the biggest failures. It is even laid out in their technical and organizational measures document.
Software companies should really be held more accountable for outright lies like this. It's a very widespread practice.
Agreed, in fact LastPass should be heavily fined for this and be forced to go out of business if things don't provably change within a reasonable timeframe.
Re: Bitwarden design flaw: Server side iterations
#143> This means that you need a strong master password. And the only real way to get there is generating your password randomly. Hm but how will I remember that? Maybe I’ll use a different password manager… :)
> Maybe I’ll use a different password manager
I do that.
I use pass https://www.passwordstore.org/> to store and get my BitWarden master PW. Pass is encrypted by a PGP key residing on my HW token/smart card and encrypted with a good but (for me) memorable PW.
In my case it's not really due to paranoia, but as I already had pass in use for critical and very important credentials before, and as I 1) was only evaluating BitWarden first and 2) did not want to remember two master passwords, so I went for this approach, and it works out quite well for how I use BitWarden (basically only on my workstation where I require my HW token anyway).
Re: Bitwarden design flaw: Server side iterations
#144While the practice of not updating PBKDF2 iterations is bad, I think with LastPass the problem was more the aggregate of many things, a sort-of death by a million cuts. Because truthfully, the PBKDF2 iterations count issue was relatively unimportant. Some good conjecture about it: https://neilmadden.blog/2023/01/09/on-pbkdf2-iterations/ Both Bitwarden and LastPass should improve this situation by making the iteration…
We took a similar approach to passphrase stretching in EnvKey v1 [1] (EnvKey is a secrets manager, not a password manager, but uses end-to-end encryption in a similar way). We used PBKDF2 with iterations set a bit higher than the generally recommended levels, as well as Dropbox's zxcvbn [2] lib to try to identify and block weak passphrases. Ultimately, I think it's just not good enough. Even if you're updating iterat…
What's the difference from an eternal session?
Re: Bitwarden design flaw: Server side iterations
#145> This means that you need a strong master password. And the only real way to get there is generating your password randomly. Hm but how will I remember that? Maybe I’ll use a different password manager… :)
> Maybe I’ll use a different password manager I do that. I use pass https://www.passwordstore.org/ > to store and get my BitWarden master PW. Pass is encrypted by a PGP key residing on my HW token/smart card and encrypted with a good but (for me) memorable PW. In my case it's not really due to paranoia, but as I already had pass in use for critical and very important credentials before, and as I 1) was only evaluatin…
I'm always surprised that people disclose so easily their whole security pipeline on HN, especially when their account has their real information.
Re: Bitwarden design flaw: Server side iterations
#146Earlier quoted context omitted.
The only way around this would be to require a human to set the # of iterations independently on all client devices. Because if you change the # of iterations using your laptop, the server wouldn't be able to tell your phone that the # of iterations has changed. Instead you just wouldn't be able to log in until you ALSO manually changed that setting on your phone to match the new server configuration that you set wit…
Couldn't all clients always do a larger amount of iterations and not let that number be configurable at all?
Clients could dynamically determine a value based on performance. That way, the encyption gets more secure the better the hardware gets.
Re: Bitwarden design flaw: Server side iterations
#147I once leaned heavily upon Google Chrome as my password manager, but then I discovered that you could view the passwords in Chrome for Windows by knowing my Windows login password, instead of my Google password. This feels off topic a little, but in all the discussion of password managers lately, I seldom hear people talk about the web browser being a good/bad idea. It almost feels like they are slipping through the…
I personally use Firefox Sync (it's built in the browser) and am very happy with it.
Re: Bitwarden design flaw: Server side iterations
#148I self-host bitwarden and you should too! You get the premium features for free when you self host
This is an excellent step by step tutorial that tells you how to self host it: https://www.youtube.com/watch?v=eCJA1F72izc
Re: Bitwarden design flaw: Server side iterations
#149While the practice of not updating PBKDF2 iterations is bad, I think with LastPass the problem was more the aggregate of many things, a sort-of death by a million cuts. Because truthfully, the PBKDF2 iterations count issue was relatively unimportant. Some good conjecture about it: https://neilmadden.blog/2023/01/09/on-pbkdf2-iterations/ Both Bitwarden and LastPass should improve this situation by making the iteration…
> Both Bitwarden and LastPass should improve this situation by making the iteration count automatically increase over time. Bitwarden does let you increase the number of PBKDF2 iterations through a setting, they they also provide this warning: > Warning: Setting your KDF iterations too high could result in poor performance when logging into (and unlocking) Bitwarden on devices with slower CPUs. We recommend that you…
Nit: yes, it's true that making the iteration count high could actually make some devices unlock very slowly. BUT:
- This only occurs when performing key derivation, i.e. when you're unlocking. It does not matter once the key is in memory. Therefore, it's actually OK if it takes a few seconds. When unlocking with biometrics, the key derivation function is not used, so on mobile devices, this occurs even less often.
- PBKDF2 is very fast. A few hundred thousand iterations is not going to be a noticeable hitch on old SoCs anymore. I actually suspect the real problem was JavaScript/webextensions/the web vault. However, it's probably a non-issue now that all browsers have decent WebCrypto implementations with PBKDF2 support. The difference between JS and native code is very noticeable with cryptographic code. Even then, it might be less of a problem now with improvements to JavaScript engines and WASM.
I generally pick open source solutions over closed source ones, and Bitwarden does check that box, but to be fair, so does KeePass XC and compatible mobile companions. I like Bitwarden as an easy tool to recommend to friends, but for power users KeePass XC is certainly worth a look. They came out looking pretty good when security researchers began approaching ways to attack the clients themselves:
Re: Bitwarden design flaw: Server side iterations
#150Earlier quoted context omitted.
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?
If it's not opensource, you cannot know if the claim of it being end2end encrypted is actually true or not. The thirdparty can disable the encryption with the click of a button.