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

221–230 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#221

Post by e12e »

adament wrote: post #132
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 f…

> If you know that your password has high entropy (>128 bit)

I don't think that is practical for most users - 12 words (or 10 taken from a 10k list) - or 22 random alphanumeric characters - is hard to remember - and long enough that they are difficult to type correctly. 70 bits might be a more sensible goal - but still long. (6/7 words, 12 characters from a set of 62).

This is the "trust anchor", so something the user needs to remember and type in - from what I've seen - remembering/representing and inputting 128 random bits is tricky.

And with modest stretching and a salt, probably overkill anyway.

Re: Bitwarden design flaw: Server side iterations

#223

Post by e12e »

realitysballs wrote: post #40
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…

Can someone Eli5 iterations in this context?

If your (binary, derived 128 bit) encryption key is the key your treasure chest - then the "derivation" is a map from your password ("hunter2") to the where the key (011101...) is buried.

With plain derivation, the map takes you directly from the password to the key. With an extra iteration, the map just points to a place on the map where a trail starts.

If you want to guess the key, by guessing the password - now you have to first walk to were the password points on the map, then follow the path (the iterations) - then dig and see if the key is there. Then you can try the key in the chest (the encrypted data).

The iterations (length of path) adds a certain, predictable, amount of work in order to find the key. It does not make it harder to guess the password, just harder to get the key from the password - and so it makes it harder to check if you've guessed the right password (try the key in the lock) - because there's extra work to be done.

Now you could compare memory-hard paths and compute-hard paths by adding elevation and distance to the analogy (different types of hard work).

Re: Bitwarden design flaw: Server side iterations

#225

Post by e12e »

kadoban wrote: post #117
hanniabu wrote: post #92

Earlier quoted context omitted.

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

18 random characters out of 36 is equivalent to ~93 bits of entropy[1]- that's pretty conservative indeed.

I would aim for 70 bits (safely north of 64 bits) - the paranoid for 96..128 bits.

[1] 18*log2(36) ~ 93

Re: Bitwarden design flaw: Server side iterations

#226

Post by nebulous1 »

> In case you are wondering whether it is even possible to implement server-side iterations mechanism correctly: yes, it is. One example is the onepw protocol Mozilla introduced for Firefox Sync in 2014. While the description is fairly complicated, the important part is: the password hash received by the server is not used for anything before it passes through additional scrypt hashing.

> Firefox Sync has a different flaw: its client-side password hashing uses merely 1,000 PBKDF2 iterations, a ridiculously low setting. So if someone compromises the production servers rather than merely the stored data, they will be able to intercept password hashes that are barely protected. The corresponding bug report has been open for the past six years and is still unresolved.

Is this not always going to be a flaw with server-side iterations? And therefore knocks down the first paragraph's contention that it's possible to do server-side iterations correctly?

Re: Bitwarden design flaw: Server side iterations

#227

Post by e12e »

aidenn0 wrote: post #78
runnerup wrote: post #68

Earlier quoted context omitted.

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?

It will theoretically increase the entropy until the total entropy exceeds the length of the hash (not the total length of the input). What we really care about is how hard it is to determine the passphrase given the hash. With a 128 bit hash, an attacker requires an average of 2^127 guesses if they are guessing completely randomly. So as long as your passphrase is well before the first 2^128 guesses an attacker is l…

Agreed - but note that 7 diceware words is still 90 bits of entropy - much less than 128, but still a pretty good password!

Re: Bitwarden design flaw: Server side iterations

#228

Post by moughxyz »

The way we solve server-side iterations with Standard Notes (which uses Argon2 and not PBKDF2) is to tie the derivation parameters (iterations, bytes, etc) to a hard-coded protocol version number. Accounts which register today for example have a protocol version of 004, which corresponds to specific, immutable derivation parameters.

For a given user, the client then receives from the server not key derivation parameters, but the version of the account. The client then maps that version to the precompiled derivation parameters.

Of course a server can then misreport a user's account version to something lower than it actually is. There are two solutions we implement here:

1. Deprecate older versions as quickly as possible after new protocol version rollouts. Older versions begin to get rejected by clients and clients will not allow sign in to proceed.

2. Allow an optional sign-in flag users can check called "Strict sign in" that forces the client to reject any server provided version that is not specifically the latest version. This means that if a user checks this option and the server reports a version != 004, the sign in will be rejected and the client will not perform any sort of handshake with the server.

More here: https://standardnotes.com/help/security/encryption

Re: Bitwarden design flaw: Server side iterations

#229

Post by moughxyz »

nebulous1 wrote: post #226

> In case you are wondering whether it is even possible to implement server-side iterations mechanism correctly: yes, it is. One example is the onepw protocol Mozilla introduced for Firefox Sync in 2014. While the description is fairly complicated, the important part is: the password hash received by the server is not used for anything before it passes through additional scrypt hashing. > Firefox Sync has a different…

It is largely unsolvable if you rely fully on the server. I describe here how we handle this at Standard Notes where the client can reject weak parameters from the server: https://news.ycombinator.com/item?id=34506062

Re: Bitwarden design flaw: Server side iterations

#230

Post by davoneus »

5e92cb50239222b wrote: post #94
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…

keepassxc does this the right way — you're not picking the "iteration count" (which is hard enough to understand even for someone relatively technically inclined), but the time it takes to open the database. The default is 1 second, with the minimum of 100 ms. "Higher values offer more protection, but opening the database will take longer". I highly recommend keepassxc to everyone instead of these password-solutions-…

Recommended away, but ease of use matters. I can use, and am comfortable with keepassxc, but there is no way in he* my wife, daughter or parents would be. It was hard enough getting them used to using BitWarden.
Post reply on HN