Bitwarden design flaw: Server side iterations • Hacker News Board

Re: Bitwarden design flaw: Server side iterations

#201

Post by rcxdude » Tue, Jan 24, 2023, 1:54 PM UTC

doodlesdev wrote: post #2

Other than the low amount of default iterations (at least compared to the OWASP recommendation [0]) the article doesn't explain why the server-side hashing is "useless" and what the design flaw actually is. Am I missing something? [0]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

It's useless in most circumunstances: it depends on what the attacker has access to. If the attacker only has the master password hashes the server uses to gate access to the encrypted database, then they would need to go through the full 200,000 iterations. But if they have the encrypted database then they can run 100,000 iterations and just try to decrypt the database (assuming this check is cheaper than the 100,000 iterations, which it likely is). And it's far more likely the attacker has the encrypted database (which can be pulled off of any machine which has been logged in, as well as the same database which contains the master password hash, if bitwarden's servers were to be breached) than the master password hash alone.

Re: Bitwarden design flaw: Server side iterations

#202

Post by Tostino » Tue, Jan 24, 2023, 1:55 PM UTC

Aicy wrote: post #154

TylerE wrote: post #38

Earlier quoted context omitted.

10ms (or whatever) of computer time is a lot cheaper than 2 seconds of mine

Not for the company paying for the compute

2 second login times can drive away enough customers to make it be the case.

Re: Bitwarden design flaw: Server side iterations

#203

Post by nicoburns » Tue, Jan 24, 2023, 1:58 PM UTC

netheril96 wrote: post #191

drowsspa wrote: post #188

Earlier quoted context omitted.

The obvious question is: what if you lose both keys? Deep down, I think it's something that requires cooperating with real world entities (governments, banks, basically real world trust), not something that tech bros seem to want to do for ideological reasons

Stop. Humans are the weakest link in security, and doubly so for humans with less training and accountability than myself. We have already seen cases of SIM swapping attacks. I don’t want to see this to be more widespread.

Only because companies are trying to do this human verification on the cheap. SIM swapping-alike attacks aren't a problem with institutions like banks where they keep ID on file and you can visit in person to prove your identity.

Re: Bitwarden design flaw: Server side iterations

#204

Post by rcxdude » Tue, Jan 24, 2023, 1:58 PM UTC

andmarios wrote: post #169

I am not sure I get the flaw. The author says that the problem is an attacker only needs 100,000 iterations to get the master password hash, instead of doing the 100,000+100,000 iterations to get the master password and the master password hash. Wouldn't though the master password hash be so long, that 100,000 iterations would be really hard to brute-force?

The point is it goes master password -> encryption key -> master password hash. The master password hash is only important if you want to download the database from bitwardan's server, the real valuable part is the encryption key, and the attacker is extremely unlikely to have the master password hash but not the encrypted database which they can use to check the encryption key.

Re: Bitwarden design flaw: Server side iterations

#205

Post by fluidcruft » Tue, Jan 24, 2023, 2:07 PM UTC

I have been thinking about this and one way to resolve it is if the encryption data and the login cannot be linked without going through the server iterations. The reason this matters is because the salt for the hashing is the email address. Attacking the encryption key directly requires knowing the corresponding email. So denying attackers that knowledge adds to their burden.

If the customer/vault records can only be linked via the server side encryption the attackers with the vaulrs and list of user emails will have to test every email as salt (also reqires some care to ensure logs can't be used to correlate vaults and emails, but all the scenarios I've played out make me think this is possible). In fact I think they could physically separate the customer and vault databases entirely to different servers or datacenters.

Initially I thought this might be what Bitwarden does (it seemed pretty clever), but the database schema on github does indeed directly/explicitly link customers and vaults.

If the customer and vault datasets were independent, Bitwarden could further complicate attacks by filling the customer and vault databases with convincingly fake entries since the basic database attack surface would scale as the product of customers and vaults.

Re: Bitwarden design flaw: Server side iterations

#206

Post by stefs » Tue, Jan 24, 2023, 2:11 PM UTC

drowsspa wrote: post #188

bigiain wrote: post #179

Earlier quoted context omitted.

Apples solution for this with their new hardware 2fa stuff is to not let you turn it on without registering two hardware keys. So perhaps forcing two enrolled devices might work? (I have all my totp seeds on my iPhone and my iPad, for that reason.)

The obvious question is: what if you lose both keys? Deep down, I think it's something that requires cooperating with real world entities (governments, banks, basically real world trust), not something that tech bros seem to want to do for ideological reasons

> governments, banks, basically real world trust

surely you're joking, mr. drowsspa

Re: Bitwarden design flaw: Server side iterations

#207

Post by rascul » Tue, Jan 24, 2023, 2:23 PM UTC

karlkloss wrote: post #110

I, personally, think that password managers contradict the idea of passwords. A password is something that YOU know. You and nobody else. Ideally not even the system you access. If you write it down, give it to somebody else, put it in the cloud, etc., the password isn't safe anymore. If you can't remember your passwords, then use something else.

> If you can't remember your passwords, then use something else.

Not practical to remember hundreds of long, randomly generated passwords, so I use something else such as a password manager that only I can access.

Re: Bitwarden design flaw: Server side iterations

#208

Post by tablespoon » Tue, Jan 24, 2023, 2:32 PM UTC

jchw wrote: post #17

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…

> I think with LastPass the problem was more the aggregate of many things, a sort-of death by a million cuts.

That's true.

> Because truthfully, the PBKDF2 iterations count issue was relatively unimportant.

IIRC, some people's LastPass vaults were set to use a very old default of a single PBKDF2 iteration, which I understand is basically nothing, nowadays.

Re: Bitwarden design flaw: Server side iterations

#209

Post by orra » Tue, Jan 24, 2023, 2:33 PM UTC

sircastor wrote: post #53

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.

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

That's important to realise, in case your (normal) second factor is a different Bitwarden device!

Re: Bitwarden design flaw: Server side iterations

#210

Post by jerf » Tue, Jan 24, 2023, 2:38 PM UTC

tablespoon wrote: post #208

jchw wrote: post #17

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…

> I think with LastPass the problem was more the aggregate of many things, a sort-of death by a million cuts. That's true. > Because truthfully, the PBKDF2 iterations count issue was relatively unimportant. IIRC, some people's LastPass vaults were set to use a very old default of a single PBKDF2 iteration, which I understand is basically nothing, nowadays.

As of three weeks ago, mine was set to 500, so I can confirm that low, at least.

Plenty of master password changes in the past several years, so plenty of opportunities for it to have been automatically set higher. The only reason I hadn't set it higher myself is I didn't know it was a setting at all.