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

131–140 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#131

Post by pilif »

masklinn wrote: post #114
pilif wrote: post #93

Earlier quoted context omitted.

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

so it would log other devices out, but not the device you're currently looking at. I think that's still an acceptable behavior compared to have people stuck with iterations counts of 500 or even 1 as we had seen in LastPass

Re: Bitwarden design flaw: Server side iterations

#132

Post by adament »

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 am not a cryptographer but to my understanding, the number of PBKDF iterations is really only of concern for weak (low-entropy) passwords. If you know that your password has high entropy (>128 bit), for example because you generated it randomly uniformly from at least 2^128 possible outcomes[1], you are safe even if you used only 1 iteration. PBKDF is all about password strengthening, so if you are making changes for yourself the most effective change is just to use a secure password and stop worrying about key derivation functions.

[1] 28 characters in a single case, 23 characters if both upper and lower case are used, 22 characters if you include numbers, 12 words if you use a word list of 2000 words and sample uniformly

Re: Bitwarden design flaw: Server side iterations

#133

Post by EspadaV9 »

jve wrote: post #126
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…

Some warning to users: Changing iterations MAY corrupt your data: > Making changes in a session with a “stale” encryption key will cause data corruption that will make your data unrecoverable. https://community.bitwarden.com/t/increasing-kdf-interations... https://news.ycombinator.com/item?id=34152181 EDIT: Look below, this actually applies to changing master password.

That is when you change your master password, or rotate your encryption keys, not changing the number of iterations (as far as I can tell).

From what I read, changing the number of iterations is safe to do.

Re: Bitwarden design flaw: Server side iterations

#134

Post by daveoc64 »

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.

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

That's the theory of passwords, but it has been demonstrated that most people simply can't manage their passwords.

I have about 600 passwords stored in my password manager.

Without a password manager, I'd have to reuse passwords (either partially or fully) to manage all of that.

A much better option is to get my password manager to generate a random password for each of those sites.

My Hacker News password, for example, is 60 characters long and contains upper and lower case letters, numbers, and symbols.

Re: Bitwarden design flaw: Server side iterations

#135

Post by ocdtrekkie »

plaguepilled wrote: post #128
ocdtrekkie wrote: post #103

Earlier quoted context omitted.

I will agree with you end user devices are generally safer. No points for ISPs being useful for anything, because they tend not to be, but firewalls for sure, and of course, the best accidental security protection ever developed: NAT. The other big difference is that end users have a single user's credentials, which is way less exciting than popping a large provider which can compromise millions of users at once. Tha…

There's an interesting general argument you're making here and I'm not prepared to immediately reject it, but one detail I will push back on hard is "use low complexity passwords for unimportant accounts". This is inadvisable. While the accounts direct utility may not be high, and it increases user overhead, a malicious party can accumulate access to tens of a user's "low value" accounts to farm metadata or incidenta…

I'd generally say anything you save payment info in for general physical purchases should probably be secured decently. But consider: Social media accounts used for public posting present no additional metadata. The risk profile to many accounts being stolen is "they can see my already public content, and also pretend to be me on that site". Which is of limited value. I'd really hope nobody trusted a sensitive transaction solely based on my HN posts, for instance. (It's definitely fair though that many people are not a good judge of this particular risk assessment.)

And I'd say for many sites, using a one-time password that you immediately don't bother to save is also probably a reasonable step up from this. If it remembers you on all your computers for a while... just lose the credentials and reset it later.

Re: Bitwarden design flaw: Server side iterations

#136

Post by pscho »

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.

> Ideally not even the system you access.

But you really can't know if the system handles passwords correctly or just stores them as plain text into a database. And memorizing a unique password for each system you want to access seems like a hard task.

Re: Bitwarden design flaw: Server side iterations

#137

Post by aflag »

runnerup wrote: post #74
ChrisSD wrote: post #63

> Even if you configure your account with 1,000,000 iterations, a compromised Bitwarden server can always tell the client to apply merely 5,000 PBKDF2 iterations to the master password before sending it to the server. The client has to rely on the server to tell it the correct value, and as long as low settings like 5,000 iterations are supported this issue will remain. This seems like a serious flaw that completely…

The only way around this would be to require a human to set the # of iterations independently on all client devices. Because if you change the # of iterations using your laptop, the server wouldn't be able to tell your phone that the # of iterations has changed. Instead you just wouldn't be able to log in until you ALSO manually changed that setting on your phone to match the new server configuration that you set wit…

Couldn't all clients always do a larger amount of iterations and not let that number be configurable at all?

Re: Bitwarden design flaw: Server side iterations

#138

Post by nirse »

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?

The _pass_ tool is an nice simple offline password manager, based on PGP, which works well for me. But I don't expect to be the victim of a targeted attack.

Re: Bitwarden design flaw: Server side iterations

#139

Post by Dylan16807 »

cl3misch wrote: post #123
nucleardog wrote: post #73

Earlier quoted context omitted.

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…

If there are 12^2 = 144 boxes total, you only need to open 2. Not 12 as you said. Put differently: with x^y nested boxes, you only have to open y. The attacker has to open x^y.

No, you're thinking of something different, like making the password more complex.

While they made it confusing by using "12" for two different things, their analogy is completely correct.

Instead of each password/location having one box, it has a box within a box within a box[...]. You have to unwrap the entire stack to check if the treasure is there.

If you use an iteration count of 5000, then when you log in you unfortunately have to do 5000 hashes. But an attacker has to do 5000 hashes per password guess.

So a deep iteration count can't substitute for a good password, but it can make up for an extra few characters. And it's basically free to increase iterations until the wait becomes visible.

Re: Bitwarden design flaw: Server side iterations

#140

Post by eloeffler »

danenania wrote: post #102
nequo wrote: post #84

Earlier quoted context omitted.

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?

I'm not deeply familiar with Keybase's design, but speaking in broad strokes, our approach is similar. That said, one area that Keybase compromised on that we haven't is offering a web interface. It's well known among security and encryption people that you can't do serious end-to-end encryption in a web app--an attacker with access to the server can just modify the html/js payload, rendering the encryption pointless…

This is especially bothersome with Bitwarden and the reason I ditched it shortly after trying it. You can use the desktop/mobile clients, but some functions require the use of the web UI and that's a dealbreaker for me...

I wish there was a browser plugin that verifies the congruence of the web UI with upstream source - or even better a client that supports all functions that the web UI supports.

Post reply on HN