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

61–70 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#61

Post by runnerup »

FreakLegion wrote: post #57
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…

I don't think "on top" gets explicit guidance, but it's also almost never needed. In this case for example scrypt and yescrypt are fine to use directly. NIST has had a strong leaning toward memory-hard functions for coming up on six years now. See §5.1.1.2 in https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 .

I'm not familiar with FIPS. Is this NIST document part of requirements outlined in the FIPS publication? Which according to 20 seconds on Google, appear to be numbered 140, 180, 186, 197, 198, 199, 200, 201, and 202.

Re: Bitwarden design flaw: Server side iterations

#62

Post by ocdtrekkie »

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 anyone on the planet. A Post-It stuck to your monitor is only subject to attack from people who can visually look inside your office. Guess which is safer? Once you realize a Post-It is a better choice, and you can think of trivial ways to improve on that... why are people storing their passwords online?

Re: Bitwarden design flaw: Server side iterations

#63

Post by ChrisSD »

> 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 undermines setting a custom value, no? If an attacker gets temporary control of a bitwarden server then they can get your password in a more easily crackable form no matter what you set.

Re: Bitwarden design flaw: Server side iterations

#64

Post by danenania »

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 iteration counts automatically (which is clearly not a safe assumption, and to be fair not something we did in EnvKey v1 either), and even with safeguards against weak passphrases, using human-generated passphrases as a single line of defense is just fundamentally weak.

That's why in EnvKey v2, we switched to using high entropy device-based keys for our root encryption keys. It's a similar model to SSH, except that on Mac and Windows the keys get stored in the OS keychain rather than in the file system. Also like SSH, a passphrase can optionally be added on top of the device key.

The downside (or upside, depending how you look at it) is that new devices must be specifically granted access. You can't just log in and decrypt on a new device with only your passphrase. But the security is much stronger, and you also avoid all this song and dance around key stretching iterations.

1 - https://github.com/envkey/envkey

2 - https://github.com/dropbox/zxcvbn

Re: Bitwarden design flaw: Server side iterations

#65

Post by aidenn0 »

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 updated my master password in 2022, but my account was still set to 5000 iterations. Not increasing it on master key changes seems beyond careless.

Re: Bitwarden design flaw: Server side iterations

#66

Post by KMnO4 »

avsteele wrote: post #22
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.

If your first two statements are correct I can't see how the third can't be. If we choose our password from only ~24 chars then you can get the same effect of 100K iterations form just 4 more characters, or ~1 more dictionary word. That doesn't seem excessive

Imagine you're an adversary, and you've just stolen a list of hashed passwords.

The values you see are:

ae1fb1a0b0ee --> ???

f10abddc10a0 --> ???

What you're going to do is start bruteforcing letters until you find the matching passwords. You know that the passwords are hashed with 100k iterations, but you don't know how long the password is.

First you start with a, b, c, d, ... z. That's 26 combinations.

Then you do aa, ab, ac, ad, ... zz. That's another 26^2 (676) combinations.

The next length of aaa, aab, aac, ... zzz is >17k combinations and it keeps increasing exponentially.

Increasing the number of iterations applies a linear multiplier to the time. If it take 26ms to bruteforce all the one character hashes with 1000 iterations, it will take 2600ms with 100,000 iterations.

But increasing the password length adds a multiplier of 26 with each new character (and that's only assuming single case letters). Adding 4 extra letters is actually an improvement of over 450,000x (26^4).

(Assuming you are using the printable ASCII character set, that's actually 95^4 = 81,450,635x)

Re: Bitwarden design flaw: Server side iterations

#68

Post by runnerup »

SAI_Peregrinus wrote: post #21
azeemba wrote: post #14

Earlier quoted context omitted.

Number of iterations being discussed is how many times the password is hashed. It is a setting the system chooses and is independent of the password length the user chooses. If you are asking if the length of the password by itself be sufficient to create a secure password, then the answer is mostly no. You need many iterations of the hashing process otherwise brute force attacks become trivial given today's hardware…

Unless you have a high-entropy long password. 10 Diceware words (words chosen uniformly at random from a list of 7776 words) is over 128 bits of entropy, even a very fast hash would be enough for such a passphrase. Of course at that point you've essentially memorized a cryptographic key, not a traditional low-security password. Good for the master password of a password database, not so usable anywhere else.

I'm not super practiced in hashing theory. If the 10 words were usually longer than the hash function output (say, starting at an average of 7 words), would adding more characters (words) still increase the entropy or would the entropy get truncated?

Re: Bitwarden design flaw: Server side iterations

#69

Post by aidenn0 »

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…

It doesn't completely undermine it; if someone were to get a dump of the BW database, it would still make it harder to crack the stored hashes.

Re: Bitwarden design flaw: Server side iterations

#70

Post by masklinn »

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…

> 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 however long it takes to convert the store (then again for most people I’d assume the payload is not enormous).

> assuming that scrypt and argon are more resilient to hardware brute-forcing

They are but needing to update the work factor as hardware progresses remains. In fact scrypt and argon have more work factor knobs than pbkdf2, which only has the iterations count.

Post reply on HN