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

51–60 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#51

Post by vena »

sircastor wrote: post #30
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 upped mine to more than 1M and haven’t seen any degradation of performance.

did you fully log out/in or just lock/unlock?

iirc locking with BW doesn’t do what one might expect wrt encryption state.

Re: Bitwarden design flaw: Server side iterations

#52

Post by ywain »

vena wrote: post #51
sircastor wrote: post #30

Earlier quoted context omitted.

I upped mine to more than 1M and haven’t seen any degradation of performance.

did you fully log out/in or just lock/unlock? iirc locking with BW doesn’t do what one might expect wrt encryption state.

Changing the number of iterations should automatically log you out on all devices. At least it did for me.

Re: Bitwarden design flaw: Server side iterations

#53

Post by sircastor »

vena wrote: post #51
sircastor wrote: post #30

Earlier quoted context omitted.

I upped mine to more than 1M and haven’t seen any degradation of performance.

did you fully log out/in or just lock/unlock? iirc locking with BW doesn’t do what one might expect wrt encryption state.

It forced me out of all my logged in instances. I had to login to everything. With my master password and my 2nd factor.

Re: Bitwarden design flaw: Server side iterations

#54

Post by vena »

ywain wrote: post #52
vena wrote: post #51

Earlier quoted context omitted.

did you fully log out/in or just lock/unlock? iirc locking with BW doesn’t do what one might expect wrt encryption state.

Changing the number of iterations should automatically log you out on all devices. At least it did for me.

oh good, didn’t know if it would do that/force a cache invalidation for clients

Re: Bitwarden design flaw: Server side iterations

#55

Post by jdeibele »

Someone1234 wrote: post #26
Aeolun wrote: post #20

Earlier quoted context omitted.

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.

And less resilient. If your notebook is destroyed (e.g. dog eats it, fire, water damage, et al) then all your passwords are gone. With most good password managers you can actually backup and store a copy of your vault data locally.

I installed BackBlaze years ago for my 88-year-old mother-in-law. She has a binder besides her computer with a sheet for each account, some with 7 or 8 passwords scratched out and replaced.

I really should have her write out a few key passwords and put them in an envelope for me to keep.

Re: Bitwarden design flaw: Server side iterations

#56

Post by sircastor »

realitysballs wrote: post #40
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…

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 that it’s difficult for them, but not so many that it’s annoying for us.

That might be a little too much “like I’m 5”, but that’s the general idea. Hashing is easy one way but it still requires compute cycles to do each iteration. We don’t want to make it excessively expensive for us.

Re: Bitwarden design flaw: Server side iterations

#57

Post by FreakLegion »

pilif wrote: post #47

Tangentially 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…

I don't think "on top" gets explicit guidance, but it's also almost never needed. In this case for example scrypt and yescrypt are fine to use directly. NIST has had a strong leaning toward memory-hard functions for coming up on six years now. See §5.1.1.2 in https://pages.nist.gov/800-63-3/sp800-63b.html#sec5.

Re: Bitwarden design flaw: Server side iterations

#58

Post by 416chad »

aarc wrote: post #46

Good to have the heads up. I just bumped my KDF iterations from 100000 to 600000. One thing that is also worth mentioning for anyone nervous about their password security is that you can use a physical security key with the paid version of Bitwarden. I need to use a yubikey to log in to any new instance of Bitwarden and it's been working well.

As I understand it, the OTP factor only protects the login. While this is still good practice, it wouldn't help in the event the vaults are stolen.

Re: Bitwarden design flaw: Server side iterations

#59

Post by skippyhammond »

gclawes wrote: post #45

Holy shit, firefox is only using 1000 iterations?

Not to excuse the behavior in that bug, but the situation is very different for Firefox than for BitWarden - as the blog post notes, 1000 iterations is only used for the key as it is in-flight via https to Mozilla's production servers, not when it is at rest. An attacker getting access to any encrypted databases would need to deal with scrypt, not these 1000 PBKDF2 iterations.

Re: Bitwarden design flaw: Server side iterations

#60

Post by eyelidlessness »

ywain wrote: post #43
realitysballs wrote: post #40

Earlier quoted context omitted.

Can someone Eli5 iterations in this context?

Iterations refer to the number of times the password goes through the hash function. The higher the number, the longer it takes, so you want it low enough that it doesn't impact your day-to-day use but high enough that it will hinder an attacker in case the hashed password is leaked.

Maybe overly pedantic to expand on this, but since we’re in an ELI5 context: the attack vector is brute forcing hash collisions. Making it computationally slow for attackers is a hindrance because the relative value of a collision diminishes over time (depending on the value of their target).
Post reply on HN