Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitwarden design flaw: Server side iterations

palant.info

Post reply on HN
Print view View original

11–20 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#11

Post by ywain »

Oof, my Bitwarden account was created a while ago and was set to only 5,000 iterations. You can see and change the number of iterations here: https://vault.bitwarden.com/#/settings/security/security-key... (or if you don't trust links for something like your password manager: log into your web vault, click on the top-right dropdown menu, then Account settings > Security > Keys).

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).

Re: Bitwarden design flaw: Server side iterations

#12

Post by amarshall »

soheil wrote: post #3

If you think it's ok to be putting all your passwords on some random server owned by a random company then I don't know if you care about any other design flaws. This also includes the websites you visited and just happened to either accidentally or on purpose save your login. Now multiply the privacy/security implications of that when said company is pumped and dumped by a major VC.

From https://infosec.exchange/@epixoip/109585049354200263 (found spelunking from OP):

> consider the fact that the threat model for a cloud-based password management solution should start with the vault being compromised. In fact, if password management is done correctly, I should be able to host my vault anywhere, even openly downloadable (open S3 bucket, unauthenticated HTTPS, etc.) without concern. I wouldn't do that, of course, but the point is the vault should be just that -- a vault, not a lockbox.

Re: Bitwarden design flaw: Server side iterations

#13

Post by ajorgensen »

ywain wrote: post #11

Oof, my Bitwarden account was created a while ago and was set to only 5,000 iterations. You can see and change the number of iterations here: https://vault.bitwarden.com/#/settings/security/security-key... (or if you don't trust links for something like your password manager: log into your web vault, click on the top-right dropdown menu, then Account settings > Security > Keys). I've updated it to 600,000 iterations…

oof me too thanks for the nudge to check!

Re: Bitwarden design flaw: Server side iterations

#14

Post by azeemba »

avsteele wrote: post #10

I 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.

Number of iterations being discussed is how many times the password is hashed. It is a setting the system chooses and is independent of the password length the user chooses.

If you are asking if the length of the password by itself be sufficient to create a secure password, then the answer is mostly no. You need many iterations of the hashing process otherwise brute force attacks become trivial given today's hardware.

Re: Bitwarden design flaw: Server side iterations

#15

Post by kadoban »

avsteele wrote: post #10

I 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.

Re: Bitwarden design flaw: Server side iterations

#16

Post by kadoban »

soheil wrote: post #3

If you think it's ok to be putting all your passwords on some random server owned by a random company then I don't know if you care about any other design flaws. This also includes the websites you visited and just happened to either accidentally or on purpose save your login. Now multiply the privacy/security implications of that when said company is pumped and dumped by a major VC.

Even a fairly middling password manager implementation is better than just about any other strategy that anyone is likely to use.

Especially because for the vast majority, the other strategy is going to be reusing the same password ~everywhere and if you're lucky the might use a special password for their bank or something.

Re: Bitwarden design flaw: Server side iterations

#17

Post by jchw »

While 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 count automatically increase over time. For LastPass though, there are... A lot of concerns. The breach, how it was handled, persistent issues with the security of their browser extension (many, including an RCE at one point) and of course the fact that not everything in the vault is actually encrypted.

KeePass XC or 1password may prove to be better options from a strict security practices standpoint, but from what I've seen I don't suspect Bitwarden has a pattern of bad security practices overall. It does seem like there are opportunities to make it better, though.

Re: Bitwarden design flaw: Server side iterations

#18

Post by Aeolun »

azeemba wrote: post #14
avsteele wrote: post #10

I 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.

Number of iterations being discussed is how many times the password is hashed. It is a setting the system chooses and is independent of the password length the user chooses. If you are asking if the length of the password by itself be sufficient to create a secure password, then the answer is mostly no. You need many iterations of the hashing process otherwise brute force attacks become trivial given today's hardware…

A sufficiently difficult password is unguessable even with a single hash.

Re: Bitwarden design flaw: Server side iterations

#19

Post by mkasberg »

ywain wrote: post #11

Oof, my Bitwarden account was created a while ago and was set to only 5,000 iterations. You can see and change the number of iterations here: https://vault.bitwarden.com/#/settings/security/security-key... (or if you don't trust links for something like your password manager: log into your web vault, click on the top-right dropdown menu, then Account settings > Security > Keys). I've updated it to 600,000 iterations…

I had bumped mine up once before (to 200K) and I just bumped it up again to 600K. But my wife (registered several years ago, like me) was still at 5K, I just bumped hers up too. Wish Bitwarden would force this for anyone still on an old default - particularly given the LastPass compromise we just saw.

Re: Bitwarden design flaw: Server side iterations

#20

Post by Aeolun »

kadoban wrote: post #16
soheil wrote: post #3

If you think it's ok to be putting all your passwords on some random server owned by a random company then I don't know if you care about any other design flaws. This also includes the websites you visited and just happened to either accidentally or on purpose save your login. Now multiply the privacy/security implications of that when said company is pumped and dumped by a major VC.

Even a fairly middling password manager implementation is better than just about any other strategy that anyone is likely to use. Especially because for the vast majority, the other strategy is going to be reusing the same password ~everywhere and if you're lucky the might use a special password for their bank or something.

I guess for most people online, writing all their passwords down in a notebook is more secure than using a password manager. It’s just less convenient.
Post reply on HN