Bitwarden design flaw: Server side iterations • Hacker News Board

Re: Bitwarden design flaw: Server side iterations

#231

Post by upofadown » Tue, Jan 24, 2023, 5:47 PM UTC

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.

Argon2 is pretty memory hungry. Recommended defaults go up to the gigabyte range. That means that you have to be careful that you don't create a situation where the user originally encrypts their passwords on a device with lots of memory but then tries to decrypt their passwords on a system with not as much memory as was used for Argon2. Then the Argon2 implementation blows up with an out of memory error and the user has effectively lost access to their passwords.

Cache hardness might be more appropriate for situations where multiple devices are involved. Then the user just has to wait for a while if things go bad...

Re: Bitwarden design flaw: Server side iterations

#232

Post by sircastor » Tue, Jan 24, 2023, 5:49 PM UTC

orra wrote: post #209

sircastor wrote: post #53

Earlier quoted context omitted.

It forced me out of all my logged in instances. I had to login to everything. With my master password and my 2nd factor.

That's important to realise, in case your (normal) second factor is a different Bitwarden device!

I didn't even think about this. My 2nd factor is through a different app, but if I'd been using BitWarden's TOTP I wonder if I would've been stuck.

A good reminder to also have printed (or something) OTPs accessible in a safe place in case you need them.

Re: Bitwarden design flaw: Server side iterations

#233

Post by KomoD » Tue, Jan 24, 2023, 6:09 PM UTC

macrolime wrote: post #182

One way that I've many people using is to have a long random password stored on a yubikey that will be entered on long press, then you have a shorter password that you remember and type in. So when you enter your masterpassword, you first type the part of the password you remember, then long press the yubikey to get it to enter the long static password.

How would you do that?

Re: Bitwarden design flaw: Server side iterations

#234

Post by aftbit » Tue, Jan 24, 2023, 6:35 PM UTC

Why do they use PBKDF2 at all instead of more modern scrypt or bcrypt?

Re: Bitwarden design flaw: Server side iterations

#235

Post by lrem » Tue, Jan 24, 2023, 6:57 PM UTC

jim02672 wrote: post #75

pjot wrote: post #49

Earlier quoted context omitted.

Using a passphrase is the way to go. Easy to type, remember, and more secure. Obligatory xkcd: https://xkcd.com/936/

You're assuming that a) a passphrase is acceptable to the system/app and b) that people can competently pick words for a passphrase. That damn XKCD is overly simplified at best. I really wish people would stop linking to it.

Bitwarden generates good pass phrases though.

Re: Bitwarden design flaw: Server side iterations

#236

Post by kadoban » Tue, Jan 24, 2023, 7:29 PM UTC

sirsuki wrote: post #193

kadoban wrote: post #111

Earlier quoted context omitted.

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…

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 account for the scheme itself and its choices too, but I don't know how to put a number on that.

Do you see how little is actually coming from the quote? Your passphrase might as well just be "95!!!!78726653980" and if anything that's _easier_ to remember.

Compare against something like a diceware passphrase. _All_ of the entropy comes from the passphrase part, the part that's easy to remember and trivial to calculate how secure it is.

So a quote is bad because you can _make_ it secure, but you making it secure is just throwing crap at it until it's no longer functionally a quote in any real way. It's secure the same way a blank password is.

Re: Bitwarden design flaw: Server side iterations

#237

Post by runnerup » Tue, Jan 24, 2023, 8:10 PM UTC

aflag wrote: post #137

runnerup wrote: post #74

Earlier quoted context omitted.

The only way around this would be to require a human to set the # of iterations independently on all client devices. Because if you change the # of iterations using your laptop, the server wouldn't be able to tell your phone that the # of iterations has changed. Instead you just wouldn't be able to log in until you ALSO manually changed that setting on your phone to match the new server configuration that you set wit…

Couldn't all clients always do a larger amount of iterations and not let that number be configurable at all?

No, because today you pick a number of iterations that takes some "long but reasonable" amount of time. Maybe that's 2 seconds, maybe that's 2 minutes...but it's the longest your customers will put up with waiting at login.

Then 10 years from now, CPU's will have sped up a LOT so that will only take 0.2 seconds or whatever. With normal users, you could update the # of iterations every year, but that requires a login to occur so that the "new" password hash can be sent by the client. With a user who only logs in every 10 years, you have to support the # of iterations that existed when the user last logged in.

Re: Bitwarden design flaw: Server side iterations

#238

Post by runnerup » Tue, Jan 24, 2023, 8:12 PM UTC

silverwind wrote: post #146

aflag wrote: post #137

Earlier quoted context omitted.

Couldn't all clients always do a larger amount of iterations and not let that number be configurable at all?

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 lowest possible hash (your phone), which defeats the purpose of the larger iterations on the desktop machine.

Re: Bitwarden design flaw: Server side iterations

#239

Post by kadoban » Tue, Jan 24, 2023, 8:32 PM UTC

e12e wrote: post #225

kadoban wrote: post #117

Earlier quoted context omitted.

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

Yeah that sounds safe, I did end up even more paranoid than I intended.

Re: Bitwarden design flaw: Server side iterations

#240

Post by STRML » Tue, Jan 24, 2023, 8:33 PM UTC

KomoD wrote: post #233

macrolime wrote: post #182

One way that I've many people using is to have a long random password stored on a yubikey that will be entered on long press, then you have a shorter password that you remember and type in. So when you enter your masterpassword, you first type the part of the password you remember, then long press the yubikey to get it to enter the long static password.

How would you do that?

https://docs.yubico.com/yesdk/users-manual/application-otp/s...

It's a nice option, but of course you need to back up this static pw somewhere or program a bunch of keys with it.