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

81–90 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#81

Post by NoPicklez »

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

Re: Bitwarden design flaw: Server side iterations

#82

Post by plaguepilled »

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…

What about KeePassXC? CLI comes with its own risks so I would have thought it is not universally applicable.

Also what is this new rusty pass app you speak of? Sounds cool but you didn't link it. :(

Re: Bitwarden design flaw: Server side iterations

#83

Post by kumarharsh »

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…

Thanks, this was a great explanation!

Re: Bitwarden design flaw: Server side iterations

#84

Post by nequo »

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…

That sounds like a good idea. Using device-specific keys sounds a lot like Keybase to my naïve ears. Are there any major differences in your design and theirs?

Re: Bitwarden design flaw: Server side iterations

#85

Post by masklinn »

avinassh wrote: post #67

Why is the iteration needed if I choose sufficiently strong passphrase? Think 40 characters

If your password is very long and randomly generated and not used anywhere else then probably not. But it doesn’t hurt.

The iterations count regulates how fast an attacker can check a guess of the clear text.

Re: Bitwarden design flaw: Server side iterations

#86

Post by xwolfi »

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…

Or why would it have internet facing data ? At some point maybe we can just transfer stuff around ourselves especially the list of all our passwords ?

Re: Bitwarden design flaw: Server side iterations

#87

Post by ocdtrekkie »

plaguepilled wrote: post #80
ocdtrekkie wrote: post #62

Embarrassments will continue until everyone realizes all the "security experts" recommending password managers have marketing deals with them. Password managers are an awful antipattern, I've been saying it for years, and it's absolutely comical to me that people do not get the message. When one falls, it's "oh that one sucked, use this other one instead". An Internet-connected data vault is subject to attack from an…

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 "something you know and something you have". If your passwords are stored somewhere, it's just two things you have.

If, like some Bitwarden users, you backup your 2FA tokens in your password manager, 2FA is just one thing you have. An using a password poor enough for you to remember and a two-factor token is better than just two separate apps on your phone.

Re: Bitwarden design flaw: Server side iterations

#88

Post by artisticnuke »

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?

Popular movie quotes or lines from books with minor iterations are bad choices. They are somewhere out there and not as safe as one might think. Completely random choice of words is good, but it is not feasible to remember random passphrases for all of your accounts.

Other common methods include appending a particular character to each word or alternate words...creating a pattern of sort, but this again makes it difficult to remember, which was the reason why we preferred passphrases instead of passwords in first place.

Re: Bitwarden design flaw: Server side iterations

#89

Post by g_p »

416chad wrote: post #58
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.

Yes, 2FA/MFA only serves as access control, to limit who can retrieve a copy of your encrypted vault from the server (to then decrypt locally).

Like in the Lastpass scenario, if someone gets a hold of your vault from a server side backup (or compromise), then your access control is bypassed, and won't make your vault harder to decrypt.

Using MFA is definitely good practice though, as in normal circumstances an attacker will be trying to get to your vault without server side access.

Re: Bitwarden design flaw: Server side iterations

#90

Post by nilespotter »

ocdtrekkie wrote: post #62

Embarrassments will continue until everyone realizes all the "security experts" recommending password managers have marketing deals with them. Password managers are an awful antipattern, I've been saying it for years, and it's absolutely comical to me that people do not get the message. When one falls, it's "oh that one sucked, use this other one instead". An Internet-connected data vault is subject to attack from an…

Bitwarden didn't fail, there was no embarrassment. They actually encrypt the vault unlike Lastpass. There is heightened awareness around the various issues that came to light following the Lastpass attack, and PBKDF2 is one of them. In Bitwarden the iteration count is user configurable.

Note also that Bitwarden provides its server software (and there is a great alternate implementation in vaultwarden); it doesn't have to be an "internet-connected data vault".

Your position is not vindicated by TFA, but I applaud your caution and you are like 10% less of an old man howling at the moon.

Post reply on HN