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

241–250 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#241

Post by tuhriel »

nucleardog wrote: post #73
sircastor wrote: post #56

Earlier quoted context omitted.

Your master password is put in a box that’s very hard to break into. But because someone might be really determined to get in, we put that box in another box that’s just as hard to break into. And because someone might be really really determined, we keep putting those boxes in new boxes so it’s really really difficult to get to the password. But sometimes we also need to get to the password, so we use enough boxes t…

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…

Is it actually 144? Wouldn't that be the worst case scenario for the attacker? If I understand the whole thing correctly, the attacker can be lucky and find the right stack of 12 in the first try.

So basically, I would set it at around half of the 144: 72 or did I get something wrong there?

Re: Bitwarden design flaw: Server side iterations

#242

Post by ghosts_ »

hiimkeks wrote: post #192
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…

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.

Dashlane's been using argon2 for quite awhile now, AFAIK one of the only ones doing so.

Re: Bitwarden design flaw: Server side iterations

#243

Post by Kab1r »

selykg wrote: post #200
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.

The real problem is platform support. Does Argon2 have support for the various platforms that Bitwarden (or other platforms) need? You need support for browser (javascript most likely), iOS, Mac, Windows, and Android at minimum. On top of that, are the implementations all equal or is one behind in terms of speed or support? You have to have everything else fall to the lowest common denominator. My guess is that that…

There's a PR for a WASM implementation of Argon2 in the Bitwarden JavaScript Clients Repository

Re: Bitwarden design flaw: Server side iterations

#244

Post by kadoban »

aurantia wrote: post #190
artisticnuke wrote: post #88

Earlier 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. Completely random choice of words is good, but it is not feasible to remember random passphrases for all of your accounts. Other common methods include appending a particular character to each word or alternate words...creating a pattern of sort, but this again makes it diff…

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

Re: Bitwarden design flaw: Server side iterations

#245

Post by tuhriel »

kadoban wrote: post #236
sirsuki wrote: post #193

Earlier quoted context omitted.

Considering length is key in computing “strength” I’m curious how using a long dialog from a movie might make it bad? Presuming you account for the full 95 entropy set (numbers, upper/lower letters, special characters) and padding¹ then how would an attacker know that a failed phrase failed because it was the wrong phase or because they forget to add some padding that is still unknown. From a dictionary/rainbow table…

The only entropy that has is: 1) the choice of quote. Say that's in the top ten quotes ever, so something like 3 or so bits of entropy. 2) the modifications and additions to the quote. Really depends what the scheme is, but few bits for which words are capitalized (~4), few bits for where the hyphen is (~3), few bits for how many bangs (~4), and a bunch of bits for which number goes on the end, (~30ish). Some bits to…

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 say I use my girlfriends name, surname and birthdate. If someone targets me directly, definitely a bad idea. For a random bruteforcer or even a dictionary attack with rockyou.txt, as an example, it wouldn't change a thing.

Or do I miss something here?

Re: Bitwarden design flaw: Server side iterations

#246

Post by aflag »

runnerup wrote: post #238
silverwind wrote: post #146

Earlier quoted context omitted.

Clients could dynamically determine a value based on performance. That way, the encyption gets more secure the better the hardware gets.

How would the server know what the hash is? So you log in with your phone and its 5,000 iterations, then you log in with your desktop and it's 500,000 iterations? Then you get an updated driver for your GPU and it fixes a performance bug and now its 550,000 iterations...how the fuck would the server know what the matching hash should be that it never got sent to it? It sounds like the server would have to store the l…

Couldn't the client send the number?

Re: Bitwarden design flaw: Server side iterations

#247

Post by hendersoon »

The real vulnerability with password managers is autoupdating browser extensions. That's the disaster on the horizon. They update on their own, all the time. You can turn updates completely off but otherwise cannot control this behavior.

Eventually, a password manager's development environment will be compromised and bad actors will sneak a trojaned extension in, submitting it to Google and Mozilla and Microsoft and the rest. Your browser will update to that extension and the bad guys will get everything.

Self-hosting won't help, your homelab running vaultwarden in a docker container not exposed to the internet is no protection from this at all. 2FA won't help either when the extension itself is your enemy, it'll simply upload your entire unencrypted vault off to the bad guy on IRC or discord or whatever.

(2FA will help on individual sites supporting it, assuming you don't use your password manager to store 2FA tokens too. They all support that functionality, but you don't do that, right?)

The only way to avoid this outcome, which again is inevitable, it WILL happen eventually, is to laboriously copy/paste passwords from a separate password vault program that is not configured to autoupdate.

The thought of actually doing that makes me cringe, so I'm still using Bitwarden. I know it's coming, and hope it hits another more popular password vault first so everybody gets wise and figures out some solution to this problem. I also use Firefox which seems to have humans reviewing extensions, at least sometimes, and is less popular than Chrome.

Re: Bitwarden design flaw: Server side iterations

#248

Post by kadoban »

tuhriel wrote: post #245
kadoban wrote: post #236

Earlier quoted context omitted.

The only entropy that has is: 1) the choice of quote. Say that's in the top ten quotes ever, so something like 3 or so bits of entropy. 2) the modifications and additions to the quote. Really depends what the scheme is, but few bits for which words are capitalized (~4), few bits for where the hyphen is (~3), few bits for how many bangs (~4), and a bunch of bits for which number goes on the end, (~30ish). Some bits to…

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 larger pool of quotes, but it ends up not mattering _too_ much. If their pool of quotes is 1000 long, that's more like 10 bits of entropy (still far, far too little on its own).

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

Yeah, it's not based on anything like this. Assuming whoever implemented the password input (bitwarden in this case) isn't _maliciously_ incompetent, an attacker would get no information from a partially-correct password guess.

> Even for badly pw parts which could traced back to me. Let’s say I use my girlfriends name, surname and birthdate. If someone targets me directly, definitely a bad idea. For a random bruteforcer or even a dictionary attack with rockyou.txt, as an example, it wouldn't change a thing.

This is not completely wrong, but somewhat incomplete. Names and birthdates/years (or dates in general) are both really common parts of passwords. So an attacker will have a dictionary of common names (or ~all names, there's not that many of us), and every date that's possible to be important to someone.

So that already reduces the entropy a lot. And yeah it's bad enough if someone targets you directly that it's just a horrible idea.

The other problem with schemes like this: if you're using a password of that form, you're probably reusing it multiple places. This allows any site you have an account at to trivially access any _other_ place you have an account at. Really, really bad news.

Re: Bitwarden design flaw: Server side iterations

#249

Post by simon04 »

vaultwarden (an unofficial Bitwarden compatible server written in Rust) has been updated two hours ago via https://github.com/dani-garcia/vaultwarden/commit/2d8c8e18f7... –

- Change default Password Hash KDF Storage from 100_000 to 600_000 iterations

- Update Password Hash when the default iteration value is different

- Validate password_iterations

- Validate client-side KDF to prevent it from being set lower than 100_000

Re: Bitwarden design flaw: Server side iterations

#250

Post by runnerup »

aflag wrote: post #246
runnerup wrote: post #238

Earlier quoted context omitted.

How would the server know what the hash is? So you log in with your phone and its 5,000 iterations, then you log in with your desktop and it's 500,000 iterations? Then you get an updated driver for your GPU and it fixes a performance bug and now its 550,000 iterations...how the fuck would the server know what the matching hash should be that it never got sent to it? It sounds like the server would have to store the l…

Couldn't the client send the number?

Yes but the server has to have something stored. If the data stored was last encrypted with a hash that has fewer iterations then the client side, then

1) the data cannot be decrypted with a hash of more iterations because the server can’t undo client side hash iterations.

2) if the encrypted data is exfiltrated it will still be as easy to crack as the iterations performed for the original encryption of the data at last login ten years ago.

Post reply on HN