Question: Would there be any benefit, not just to increasing the number of hash iterations but also changing it to a random non-round number? I would have thought if you were brute-forcing the hashing key it would be worth limiting it to round numbers (e.g increments of 10,000 or 50,000) to increase the efficiency.
Bitwarden design flaw: Server side iterations
251–260 of 264 posts
Re: Bitwarden design flaw: Server side iterations
#252At least I know, so I manually increased the iterations on my account above 600,000 as a safeguard. I'll have to keep in mind to update it in the future.
Re: Bitwarden design flaw: Server side iterations
#253Earlier quoted context omitted.
> 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…
Z00jAn35RegxP7G1QMmy3dn6i5Echcd3PQAEHCBW - this password has 240 bits of entropy, how much is it?
Re: Bitwarden design flaw: Server side iterations
#254Earlier quoted context omitted.
> luckily recently there is a tool which is, ...and that is???
Not GP, but https://github.com/timvisee/prs seems to fit the bill.
Thanks for mentioning prs [1], dev here! :)
Yeah it definitely meets those requirements, being written in Rust, supporting pass, TOTP, Tombs amongst other things out of the box.
Though its CLI is slightly different than classic pass. That is on purpose in fact, to achieve a better UX and less ambiguous commands.
Re: Bitwarden design flaw: Server side iterations
#255Earlier quoted context omitted.
what I don't get with this argument, why does the quote only give 3 bits of entropy? Are the cracking algorithms so good that they know to try "or not to be" after they get to "to be". Also, as far as I remember you can't get a "you are partially there" result. Either you get the password or not. So they wouldn't know that "to be" are the first five chars. Even for badly pw parts which could traced back to me. Let’s…
> what I don't get with this argument, why does the quote only give 3 bits of entropy? Good question. 3 bits is based on the part I mentioned where "to be or not to be" is one of the top 10 quotes. log(10) is about 3. The reasoning for this is that this quote is going to be in a "dictionary" your attacker has. 10 is probably a bit unfair on my part, because an attacker is probably really going to be guessing from a l…
Thanks for the clarification.
I guess I somehow underestimated the extent of the dictionaries "available".
...and probably how they extend their search patterns.
P.s.: I wouldn't use the pattern in my example... :-)
Re: Bitwarden design flaw: Server side iterations
#256Earlier quoted context omitted.
> 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. In English. Not all books in all languages ever published are "somewhere out there".
> Not all books in all languages ever published are "somewhere out there". I mean, they mostly are or can be. What's the point on relying on "nobody happened to catalog the book I copied my passphrase from"? Are you going to check every week that nobody uploaded it to an archive site? There's easier schemes that don't rely on that.
For smaller languages the steps would be:
- Somebody would have to digitize an old book without mistakes.
- Somebody would have to publish it online.
- Somebody would have to scrape and archive that.
- Somebody would have to transliterate it to Latin script.
- That transliteration would also have be the same transliteration I'm using.
It's unlikely it will be done for a lot of languages.
> There's easier schemes that don't rely on that.
Remembering random words is hard. This is how we got into this in the first place.
Re: Bitwarden design flaw: Server side iterations
#257Earlier quoted context omitted.
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 use…
I think your point is valid and important, especially considering the average user. However in my experience it worked surprisingly well with a long word based master password. Since I only needed to remember 1 password that I then used daily it was not that difficult. And typing it was quick since it was all lowercase which most keyboards are optimized for. However the issue came when I started using my password vault on my phone and tablet. I was way too slow at typing on them. I now have a 22 character password which takes the same time for me to type on a keyboard, maybe a bit slower, but is faster on my phone though still annoyingly slow.
As for 70 bits password, it might be enough, but you need a lot of iterations (2^58) if you want to completely make up for the lost security margin. Which will also be unusably slow in practice.
Re: Bitwarden design flaw: Server side iterations
#258Oof, 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…
IMPORTANT NOTE
When you do this reset and sign back into your devices/browser plugins, you will need to go into the Bitwarden Settings on each one and set a few options again - notably timeout (defaults back to Browser Restart, change back to a time you're comfortable with), Biometric Unlock and PIN. All of those are local settings to each Bitwarden client/endpoint, so you need to do them on each device.
Re: Bitwarden design flaw: Server side iterations
#259I self-host bitwarden and you should too! You get the premium features for free when you self host This is an excellent step by step tutorial that tells you how to self host it: https://www.youtube.com/watch?v=eCJA1F72izc
I've given up trying to self host stuff like that, it's always a nightmare compared to paying for the service. Plausible Analytics being a prime example. Bitwarden can have my $10 a year.
> Plausible Analytics being a prime example.
I would say that in the case of analytics, there are more things to consider than price and ease of installation when considering self-hosting. By not self-hosting you are sending your users data to a 3rd party, which might have impact on their privacy or on the law compliance.
Re: Bitwarden design flaw: Server side iterations
#260So, as a user, what should I do now?