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

211–220 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#211

Post by Gareth321 »

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…

You are quite right. Open source software is always riddled with complicated and unintuitive UX like this. It's created by developers for developers. It's only when product owners, designers, and commercial managers get involved that the UX begins making sense.

Re: Bitwarden design flaw: Server side iterations

#212

Post by andmarios »

rcxdude wrote: post #204
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.

Ah, that makes it clear. Thank you for the explanation. :)

Re: Bitwarden design flaw: Server side iterations

#213

Post by simooooo »

Havoc wrote: post #161

Leaning towards self hosting at this stage. Sure my security skills are no match vs Bitwarden engineers…but I also don’t have a giant state actor sized bullseye painted on my back

I’m waiting for the bitwarden unified release. Then I might give it a go

Re: Bitwarden design flaw: Server side iterations

#215

Post by j1elo »

jchw wrote: post #181
j1elo wrote: post #159

Earlier quoted context omitted.

Bitwarden already takes a couple of instants more than I'd like, each time the vault is unlocked in my phone. It's always one of those moments where I'm doing something that requires a new login, and usually the step of having to derive attention to the password manager is an undesired distraction, agravated by watching an idle screen for at least a couple of seconds while the vault decides to open, and at last I can…

If you are using PIN entry: It's the same story. Key derivation is only occurring when you actually unlock the vault, in other cases the passphrase is not used and therefore key derivation is not needed. If PIN unlocks are taking too long, it has nothing to do with PBKDF2. If you're entering the master passphrase every time: Obviously this has the benefit of not keeping the derived key cached anywhere, even if where…

After reading you and checking the links, I am now sure the unlocking latency is not due to the number of iterations.

First and foremost, because I'm using the PIN entry. And it already takes some very noticeable time to open. I do not, however, notice too much difference between using PIN or the passphrase. So the delay must come from other unrelated limitations.

Thanks for all the useful info!

Re: Bitwarden design flaw: Server side iterations

#216

Post by Terretta »

Gareth321 wrote: post #211
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…

You are quite right. Open source software is always riddled with complicated and unintuitive UX like this. It's created by developers for developers. It's only when product owners, designers, and commercial managers get involved that the UX begins making sense.

"But Apple is trying to control me!" screams every dev who doesn't understand this, not realizing they are signaling their inability to empathize with normal end users and misattributing why Apple does what it does.

Apple gets it, devs don't. In this space, 1Password is least worst, yet is still more confusing than the average user quite understands.

Apple isn't a most valuable company because they want to control you. They're a most valuable company because their engineers blend software and hardware into experiences for end users not for engineers.

So much more software would be so much more successful if usability and adoption were as prioritized as utility and configurability.

Re: Bitwarden design flaw: Server side iterations

#217

Post by hiimkeks »

jchw wrote: post #198
hiimkeks wrote: post #192

Earlier quoted context omitted.

They shouldn't be using PBKDF2 for new installations at all. It's been nearly a decade since the Password Hashing Competition, and you should just use the memory-hard Argon2. Also, W3C should finally get it into the WebCrypto API, but it seems like whoever is responsible for it just let's that API rot. There are fast wasm implementations, though.

Memory-hard is not a panacea. I think the point, which is pretty well made by the blog post I linked to, is that the security of the vault is extremely sensitive to the passphrase anyways. Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort, not to mention yes, lacking Webcrypto support is a significant perfo…

> Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort

The way I see it it's the other way around. The only complexity cost that lives here is that you need to distinguish between different derivation configurations. Whether that configuration tells you to use PBKDF2-200000 or Argon2-64M-4-1 doesn't matter, and you'll have to add a clause to the code either way. On the flipside, the memory-hardness allows you to increase the cost for the attacker a lot more than for the user.

> WASM Argon2 implementations are at least multiple times slower than native IIRC

I haven't looked this up, but my suspicion is that it's still better than a WebCrypto PBKDF2 configuration taking the same time for the user, measured in Wh for the attacker.

Re: Bitwarden design flaw: Server side iterations

#218

Post by drowsspa »

stefs wrote: post #206
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

> governments, banks, basically real world trust surely you're joking, mr. drowsspa

Oh yeah, I guess we can be all about getting 10 yubikeys and keep one in your wallet, another together with your keys, another in your home, bury another in your family's farm, another in a safe in the capital city of every country you visit...

Re: Bitwarden design flaw: Server side iterations

#219

Post by drowsspa »

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.

It's even worse now, no company truly locks you out and with enough noise on social media a real human can get you your access back even if you don't have your Yubikey. So it's always vulnerable to social engineering.

Of course I'm not talking about just relying on SIM. Maybe we can stop with the knee-jerk reaction and actually think of how to add better ways to do it. Government IDs could enter as some piece of the puzzle, trusted contacts, yeah, even SIM... At the very least out here in the real world I have some recourse if my ID is stolen, and I don't have to worry about having to buy all my stuff back because I lost my keys.

As I understand it, Keybase actually has a very interesting concept of spreading key materials over your social media. So it's not even unprecedented.

Re: Bitwarden design flaw: Server side iterations

#220

Post by jchw »

hiimkeks wrote: post #217
jchw wrote: post #198

Earlier quoted context omitted.

Memory-hard is not a panacea. I think the point, which is pretty well made by the blog post I linked to, is that the security of the vault is extremely sensitive to the passphrase anyways. Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort, not to mention yes, lacking Webcrypto support is a significant perfo…

> Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort The way I see it it's the other way around. The only complexity cost that lives here is that you need to distinguish between different derivation configurations. Whether that configuration tells you to use PBKDF2-200000 or Argon2-64M-4-1 doesn't matter, an…

Just to be clear, the cost of changing the iterations is almost zero. Bitwarden already supports variable PBKDF2 rounds on all platforms, as well as changing the number of rounds. I'm sorry, but the cost of deploying Argon2 in production to a lot of platforms across a lot of devices is non-trivial by comparison. If you have enough different combinations of devices and environments deploying an if statement can become a challenge. In this case, it's especially a problem considering the lack of Webcrypto support.

By all means, use Argon2 in new code, or any other more modern KDF. But PBKDF2 isn't broken, and replacing it warrants actually doing the ground work to see if it makes sense: is it fast enough on most devices? is the security improvement meaningful enough? etc.

The truth is, 1password has the right idea here with their Master Key system. Even very unwieldy long passwords are pretty low entropy compared to a proper cryptographic key, and KDFs cannot significantly improve this situation. If you want to do more than re-inforce the speed bump, you're going to need to work outside the password. It has a usability trade-off of course, so maybe it's good that not everyone does it that way.

Post reply on HN