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

111–120 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#111

Post by kadoban »

Toutouxc wrote: post #79
jim02672 wrote: post #75

Earlier quoted context omitted.

You're assuming that a) a passphrase is acceptable to the system/app and b) that people can competently pick words for a passphrase. That damn XKCD is overly simplified at best. I really wish people would stop linking to it.

Please elaborate, how can you pick bad words for a passphrase? (Except obviously a movie title or an everyday sentence) Like, if I go "street bologna drawer sunset fang", did I do well?

There's some things that are obviously bad: popular movie quotes, slightly less bad (but still bad): any quote from anything ever produced in any medium.

Some things that are obviously good (you can calculate the entropy easily): diceware style schemes, generated with dice or a secure random generator.

Anything in the middle it's quite hard to say. Humans are really bad at being random, so words you pick out of your head I'd be fairly suspicious of. But it's hard to prove it's a bad idea.

Re: Bitwarden design flaw: Server side iterations

#112

Post by jdhendrickson »

nucleardog wrote: post #73
sircastor wrote: post #56

Earlier quoted context omitted.

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

To kinda just expand on that because I think the analogy's most of the way there: You're trying to keep something safe and all you've got is a weirdly infinite collection of cardboard boxes. So you have this brilliant idea... you get a dozen boxes and put your treasure in one of them. That's great, it's certainly safer than leaving it laying out. It'll take someone at least like... a minute to go check all dozen boxe…

Feynman would be proud. The ability to take a complex subject and break it down in such a way that nothing of value is lost but a child can understand it is rare.

Re: Bitwarden design flaw: Server side iterations

#113

Post by rstuart4133 »

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…

> 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 increase the value in increments of 50,000 and then test all of your devices.

Translation: upping this could make your old device very slow.

I'm not sure I'd want to be receiving end of a whole pile of users complaining Bitwarden is becoming unusable on their current devices because they silently upped it, so I'm be leery of upping for existing users too.

As for the server side key issue highlighted in the article: they have a point; it could be done better. But it's already pretty good, and if that's the only issue it's the least of my concerns. It's only a concern if a hacker got read access to the server, but read access means they've been compromised. And if they've been compromised those same people might have write access. If someone gets write access to Bitwarden's servers, then all bets are off. They can just modify the javascript to send themselves my unencrypted key.

Then there is the /dev/mem thing. The bottom line is if someone has access to your machines RAM, then you can likely see the entire database unencrypted. Is your Windows desktop "corporate managed"? If so, I'm looking at you, sir. While Linux / Android / iOS are more protective of their users than Microsoft (who seems hell bent on selling their soul to their corporate customers), they aren't whole pile better. They may not sell their soul to high paying corporate customers, but they will still do whatever their governments ask and you will be none the wiser.

The bottom line is all these proprietary solutions suffer from this "we won't let you see but we promise you can trust us" flaw. I refused to use LastPass because it was hopeless in that respect, and later their promises turned out to be hollow. With Bitwarden there is a lot less trust involved because we can inspect the code they promise we are running.

Re: Bitwarden design flaw: Server side iterations

#114

Post by masklinn »

pilif wrote: post #93
masklinn wrote: post #70

Earlier quoted context omitted.

> This should absolutely be application managed and gradually increased over time. One issue I could see with that is that because it’s the encryption key it’s going to lock out all your “live” devices, so an explicit step is an easy opportunity to warn them. The second issue is that the transcryption would have to be done on login, which is a pretty shit UX as the user logs in then immediately gets locked out for ho…

> One issue I could see with that is that because it’s the encryption key it’s going to lock out all your “live” devices, so an explicit step is an easy opportunity to warn them. how so? The iteration count must be part of the non-encrypted parts of the vault data. If a client is offline, it will use its locally stored vault with the old (lower) iteration count. If it's online, it will have the updated vault with the…

> how so? The iteration count must be part of the non-encrypted parts of the vault data. If a client is offline, it will use its locally stored vault with the old (lower) iteration count. If it's online, it will have the updated vault with the higher iteration count.

The iteration count affects the encryption key, and bitwarden neither has the old encryption key nor the actual password to derive either.

So the vault has to be updated at the first device connection after updating the iterations count, and any other device will have to derive the new encryption key and log back in.

Re: Bitwarden design flaw: Server side iterations

#115

Post by npigrounet »

wereallterrrist wrote: post #48

tl;dr rant, and not an exaggeration: the amount of time I've spent skimming these (edit to be nicer) exhausting comment threads about password managers has taken 10x the amount of time it took to use a pass-compatible or age-based password manager. Okay, here we go, let me be explicit: there's a Venn diagram I imagine in my head of two circles - first is "password managers that require a web ui and browser integratio…

[dead]

Re: Bitwarden design flaw: Server side iterations

#116

Post by BrightOne »

runnerup wrote: post #77
wereallterrrist wrote: post #48

tl;dr rant, and not an exaggeration: the amount of time I've spent skimming these (edit to be nicer) exhausting comment threads about password managers has taken 10x the amount of time it took to use a pass-compatible or age-based password manager. Okay, here we go, let me be explicit: there's a Venn diagram I imagine in my head of two circles - first is "password managers that require a web ui and browser integratio…

> luckily recently there is a tool which is, ...and that is???

Not GP, but https://github.com/timvisee/prs seems to fit the bill.

Re: Bitwarden design flaw: Server side iterations

#117

Post by kadoban »

hanniabu wrote: post #92
kadoban wrote: post #15

Earlier quoted context omitted.

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.

What alphanumeric password length would be sufficient enough to still be protected with only 1000 or 5000 iterations?

I don't have great values for the constants, and it's a bit of a question of who your expected adversary is, but assuming a randomly generated alphanumeric password, the equation should be something like:

Expected time to break = 1/2 * 36^L * iterations / (hashes per second your adversary can do)

So you'd want to pick how long you want this to remain secure (~50 years is probably beyond good enough). For hashes, a _very_ conservative choice might be something like the hashes per second done in all of Bitcoin, worldwide. One arbitrary result in Google suggests that that is 286,767,038,956,306,900,000 H/s.

If I did the math right, that works out to 17-18 characters long for 1000 iterations. The number of hashes per second there is obviously way too big, but I'm uncomfortable picking a lower one without doing more research than I'm interested in doing. There's probably a recommendation from some security experts out there somewhere, but I'd imagine it's going to be a bit of a struggle to get one of them to tell you anything except "use more than 1000 iterations".

Re: Bitwarden design flaw: Server side iterations

#118

Post by nine_k »

danenania wrote: post #64
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…

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 are your expected failure modes? Consider this pretty common scenario: ahe user lost their one and only enrolled device. How can the user reinstate access?

I suppose the user must have printed the real root password / secret key / whatever and put the paper somewhere in a safe. That password should allow to reinstate access when all hardware is lost. But it should not be required daily.

Re: Bitwarden design flaw: Server side iterations

#119

Post by crumpled »

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.

Offline password managers.

Re: Bitwarden design flaw: Server side iterations

#120

Post by crumpled »

ocdtrekkie wrote: post #87
plaguepilled wrote: post #80

Earlier quoted context omitted.

What about offline only managers?

Is it stored on a device which connects to the Internet? It's online! I think there's a role to play for things like KeePass when you need to share some secret values with family or team members, but it shouldn't be for high security things. Two-factor authentication is probably our best practical defense right now, and generally the best way to do that is not to have your password saved anywhere: Two-factor is "some…

Definitely still vulnerable to a targeted attack, but you have fewer attackers than a service provider does by orders of magnitude.
Post reply on HN