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

191–200 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#191

Post by netheril96 »

drowsspa wrote: post #188
bigiain wrote: post #179

Earlier quoted context omitted.

Apples solution for this with their new hardware 2fa stuff is to not let you turn it on without registering two hardware keys. So perhaps forcing two enrolled devices might work? (I have all my totp seeds on my iPhone and my iPad, for that reason.)

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.

Re: Bitwarden design flaw: Server side iterations

#192

Post by hiimkeks »

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.

Re: Bitwarden design flaw: Server side iterations

#193

Post by sirsuki »

kadoban wrote: post #111
Toutouxc wrote: post #79

Earlier quoted context omitted.

Please elaborate, how can you pick bad words for a passphrase? (Except obviously a movie title or an everyday sentence) Like, if I go "street bologna drawer sunset fang", did I do well?

There's some things that are obviously bad: popular movie quotes, slightly less bad (but still bad): any quote from anything ever produced in any medium. Some things that are obviously good (you can calculate the entropy easily): diceware style schemes, generated with dice or a secure random generator. Anything in the middle it's quite hard to say. Humans are really bad at being random, so words you pick out of your…

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 perspective I'm curious how they would know to include the following in their lookup tables before going fill number crunching mode:

  TO be or NOT two be - that is the question!!!!!!!!!!7872665398
Bitwarden suggests this is strong as does GRC Haystacks¹ thoughts?

¹ https://www.grc.com/haystacks.htm

² https://bitwarden.com/password-strength/

Re: Bitwarden design flaw: Server side iterations

#194

Post by a2128 »

karlkloss wrote: post #110

I, personally, think that password managers contradict the idea of passwords. A password is something that YOU know. You and nobody else. Ideally not even the system you access. If you write it down, give it to somebody else, put it in the cloud, etc., the password isn't safe anymore. If you can't remember your passwords, then use something else.

I think that the idea of passwords has shifted over time.

Today we are using more and more accounts, almost every website or service seems to require an account for something. It's impossible to remember strong unique passwords for 300 different websites. Anyone with that many accounts who isn't using a password management system is almost guaranteed to be re-using the same passwords or patterns.

Data breaches have also become more common and accessible to bad actors, to the point a script kiddie or hacker could look up your email, see much of your old passwords, and use that to help bruteforce your current password for some important account.

Password management defends against this by allowing you to use random meaningless passwords for each website without needing to remember each one. There is no more human element in picking your password, and your old passwords become useless for any would-be intruders.

Re: Bitwarden design flaw: Server side iterations

#195

Post by tjbiddle »

crumpled wrote: post #124

I once leaned heavily upon Google Chrome as my password manager, but then I discovered that you could view the passwords in Chrome for Windows by knowing my Windows login password, instead of my Google password. This feels off topic a little, but in all the discussion of password managers lately, I seldom hear people talk about the web browser being a good/bad idea. It almost feels like they are slipping through the…

I've bought a few online businesses; and when doing so - we of course transfer various online accounts.

Once, I was given the primary Google account and as I was going through and updating security items on that account I discovered the previous owner had been using Google's password feature and I could login to a whole slew of his personal accounts (Not just the "Login with Google" ones). Of course, I just deleted all those - but the risk of centralization was certainly highlighted in that moment.

Re: Bitwarden design flaw: Server side iterations

#197

Post by rcxdude »

eyelidlessness wrote: post #60
ywain wrote: post #43

Earlier quoted context omitted.

Iterations refer to the number of times the password goes through the hash function. The higher the number, the longer it takes, so you want it low enough that it doesn't impact your day-to-day use but high enough that it will hinder an attacker in case the hashed password is leaked.

Maybe overly pedantic to expand on this, but since we’re in an ELI5 context: the attack vector is brute forcing hash collisions. Making it computationally slow for attackers is a hindrance because the relative value of a collision diminishes over time (depending on the value of their target).

It's not really hash collisions: SHA256 is still too secure for that, you're unlikely to find a value which isn't the password used to generate it. It's just brute forcing the password

Re: Bitwarden design flaw: Server side iterations

#198

Post by jchw »

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.

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 performance problem (WASM Argon2 implementations are at least multiple times slower than native IIRC.)

Re: Bitwarden design flaw: Server side iterations

#199

Post by rcxdude »

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…

Another issue is the hash used: SHA-256 is a hash which can be calculated extremely quickly on dedicated hardware (which has been incentivised heavily by bitcoin mining). So the gap between the speed at which an attacker can run the hashes vs the intended user is larger than with other hashes, like argon2, which is specifically designed to be resistant to acceleration by dedicated hardware.

Re: Bitwarden design flaw: Server side iterations

#200

Post by selykg »

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.

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 will be browser based implementations.

This is why so many password managers continue to use PBKDF2, because it has widespread support, particularly in browsers. Until Argon2 (or others) have support that matches it, many products won't use it because it brings with it all sorts of issues.

Post reply on HN