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

121–130 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#121

Post by bjoli »

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…

600.000 was a bit too much for my 3 year old low-end android phone. 400k workes OK. when I sorted everything into folders I could bump it up to 600k probably due to time saved rendering.

Re: Bitwarden design flaw: Server side iterations

#122

Post by danenania »

nine_k wrote: post #118
danenania wrote: post #64

Earlier quoted context omitted.

We took a similar approach to passphrase stretching in EnvKey v1 [1] (EnvKey is a secrets manager, not a password manager, but uses end-to-end encryption in a similar way). We used PBKDF2 with iterations set a bit higher than the generally recommended levels, as well as Dropbox's zxcvbn [2] lib to try to identify and block weak passphrases. Ultimately, I think it's just not good enough. Even if you're updating iterat…

What are your expected failure modes? Consider this pretty common scenario: ahe user lost their one and only enrolled device. How can the user reinstate access? I suppose the user must have printed the real root password / secret key / whatever and put the paper somewhere in a safe. That password should allow to reinstate access when all hardware is lost. But it should not be required daily.

Good point. We have recovery keys for this. These are 12 word random phrases generated from a 1952 word list (about 131 bits of entropy).

They require email authentication to redeem, so a recovery key by itself isn't sufficient to access an account, though of course they do need to be protected.

An org admin can also re-invite a user that loses access this way. The only scenario where you're really in trouble is if you're the only admin, you lose access to your only authorized device, and you lose access to your recovery key.

Re: Bitwarden design flaw: Server side iterations

#123

Post by cl3misch »

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…

If there are 12^2 = 144 boxes total, you only need to open 2. Not 12 as you said.

Put differently: with x^y nested boxes, you only have to open y. The attacker has to open x^y.

Re: Bitwarden design flaw: Server side iterations

#124

Post by crumpled »

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 cracks of the conversation.

For the record, I no longer use that platform for important passwords or secrets, ("driver carries no cash")

Re: Bitwarden design flaw: Server side iterations

#125

Post by mmiyer »

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 also allows you to generate a random passphrase, which is pretty nice for those situations where you want to be able to manually type in the password.

Re: Bitwarden design flaw: Server side iterations

#126

Post by jve »

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…

Some warning to users: Changing iterations MAY corrupt your data:

> Making changes in a session with a “stale” encryption key will cause data corruption that will make your data unrecoverable.

https://community.bitwarden.com/t/increasing-kdf-interations...

https://news.ycombinator.com/item?id=34152181

EDIT: Look below, this actually applies to changing master password.

Re: Bitwarden design flaw: Server side iterations

#127

Post by NoPicklez »

mtlmtlmtlmtl wrote: post #105
NoPicklez wrote: post #81

Earlier quoted context omitted.

I still think it's maddening that LastPass's website says that the vault is encrypted, yet in reality that wasn't and may still not be the case, where aspects of the vault as we now know aren't encrypted. Unless I'm missing something, to me that is one of the biggest failures. It is even laid out in their technical and organizational measures document.

Software companies should really be held more accountable for outright lies like this. It's a very widespread practice.

100%

They tout on their website that they get third party assurance testing done and yet none of it matters if we can’t see the actual reports.

I just can’t believe more people aren’t enraged about it. Or that people aren’t seeking to sue, purely based on that. Zero trust architecture is fine if you’re breached that’s the whole point, but saying that the information within the vault is encrypted when parts of it aren’t is downright malicious.

Re: Bitwarden design flaw: Server side iterations

#128

Post by plaguepilled »

ocdtrekkie wrote: post #103
plaguepilled wrote: post #96

Earlier quoted context omitted.

Ehhhh, I dunno on that one. I think "stored on an end user device" is quite different from "stored on a server with a public address". Firewall rules differ, for one. ISPs are more restrictive on what they flag as suspicious for domestic connections for two. Yes it would be better if the password manager were airgapped but that's a bad trade off in terms of user inefficiency and risk reduction IMO. In the same way, t…

I will agree with you end user devices are generally safer. No points for ISPs being useful for anything, because they tend not to be, but firewalls for sure, and of course, the best accidental security protection ever developed: NAT. The other big difference is that end users have a single user's credentials, which is way less exciting than popping a large provider which can compromise millions of users at once. Tha…

There's an interesting general argument you're making here and I'm not prepared to immediately reject it, but one detail I will push back on hard is "use low complexity passwords for unimportant accounts".

This is inadvisable. While the accounts direct utility may not be high, and it increases user overhead, a malicious party can accumulate access to tens of a user's "low value" accounts to farm metadata or incidentally relevant data.

Additionally, the end user is not always the best judge of which accounts are even high value. My aunt insists, for example, that her Amazon account does not need a complex password because she "only" buys cookware from it. A silly example, but it illustrates the point.

Re: Bitwarden design flaw: Server side iterations

#129

Post by FreakLegion »

runnerup wrote: post #61
FreakLegion wrote: post #57

Earlier quoted context omitted.

I don't think "on top" gets explicit guidance, but it's also almost never needed. In this case for example scrypt and yescrypt are fine to use directly. NIST has had a strong leaning toward memory-hard functions for coming up on six years now. See §5.1.1.2 in https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 .

I'm not familiar with FIPS. Is this NIST document part of requirements outlined in the FIPS publication? Which according to 20 seconds on Google, appear to be numbered 140, 180, 186, 197, 198, 199, 200, 201, and 202.

Password hashing is controlled by NIST SP 800-63B, not FIPS, but FIPS supplies the approved primitives. When NIST says:

> The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC) [FIPS 198-1], any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B] or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185].

Those options are authorized by FIPS. The main consequence of this is that there are FIPS-validated implementations available, which are what you want if you're selling to the government.

Re: Bitwarden design flaw: Server side iterations

#130

Post by kadoban »

jve wrote: post #126
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…

Some warning to users: Changing iterations MAY corrupt your data: > Making changes in a session with a “stale” encryption key will cause data corruption that will make your data unrecoverable. https://community.bitwarden.com/t/increasing-kdf-interations... https://news.ycombinator.com/item?id=34152181 EDIT: Look below, this actually applies to changing master password.

> Some warning to users: Changing iterations MAY corrupt your data

This is incorrect.

https://bitwarden.com/help/what-encryption-is-used/#changing...

> When you change the iteration count, you'll be logged out of all clients. Though the risk involved in rotating your encryption key does not exist when changing KDF iteration count, we still recommend exporting your vault beforehand.

Post reply on HN