Live data from Hacker News

Bitwarden design flaw: Server side iterations

palant.info

31–40 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#31
post #20
post #16

Earlier quoted context omitted.

Even a fairly middling password manager implementation is better than just about any other strategy that anyone is likely to use. Especially because for the vast majority, the other strategy is going to be reusing the same password ~everywhere and if you're lucky the might use a special password for their bank or something.

I guess for most people online, writing all their passwords down in a notebook is more secure than using a password manager. It’s just less convenient.

A notebook is better in some ways, but worse in important ones. It can't save you from phishing, and your password strength is going to be relatively poor (since a notebook can't generate them for you, and if they get long it'll be annoying to type). Also, a notebook is easier to copy, steal, or lose (though this is a fairly minor consideration for most people).

I would say a notebook is worse than a password manager. It's not strictly worse in every way, but on the balance it's not a hard choice.

A notebook is better than most other not-a-password-manager solutions though. So it has that going for it.

Re: Bitwarden design flaw: Server side iterations

#32
post #3

If you think it's ok to be putting all your passwords on some random server owned by a random company then I don't know if you care about any other design flaws. This also includes the websites you visited and just happened to either accidentally or on purpose save your login. Now multiply the privacy/security implications of that when said company is pumped and dumped by a major VC.

From https://infosec.exchange/@epixoip/109585049354200263 (found spelunking from OP): > consider the fact that the threat model for a cloud-based password management solution should start with the vault being compromised. In fact, if password management is done correctly, I should be able to host my vault anywhere, even openly downloadable (open S3 bucket, unauthenticated HTTPS, etc.) without concern. I wouldn't do t…

I keep making this same point in various HN threads. It should be trivially obvious to anyone who understands cryptography, but I guess lots of people really just don't.

Pick a good password, pick good algorithms, and you should feel very comfortable about hosting an encrypted blob of data anywhere. Maybe you should worry a little if you're at risk of being specifically targeted by the NSA, but I doubt they've seriously broken any state-of-the-art crypto. At that point OS exploits and trojans are your real concern.

Re: Bitwarden design flaw: Server side iterations

#33
post #15

Earlier quoted context omitted.

The number of iterations scales linearly with the cost of brute-forcing. The cost scales exponentially with the length of the password, assuming a random password (stops scaling when you reach the hash size I think). Both are important because you can't freely increase the password length, they become more annoying to enter and remember.

I never enter or remember any of the passwords bitwarden generates for me, I have an app and an extension for that.

it's about the master password

Re: Bitwarden design flaw: Server side iterations

#34
post #15

Earlier quoted context omitted.

The number of iterations scales linearly with the cost of brute-forcing. The cost scales exponentially with the length of the password, assuming a random password (stops scaling when you reach the hash size I think). Both are important because you can't freely increase the password length, they become more annoying to enter and remember.

I never enter or remember any of the passwords bitwarden generates for me, I have an app and an extension for that.

This is about the password you use to log into BitWarden itself.

Re: Bitwarden design flaw: Server side iterations

#35
post #15

Earlier quoted context omitted.

The number of iterations scales linearly with the cost of brute-forcing. The cost scales exponentially with the length of the password, assuming a random password (stops scaling when you reach the hash size I think). Both are important because you can't freely increase the password length, they become more annoying to enter and remember.

I never enter or remember any of the passwords bitwarden generates for me, I have an app and an extension for that.

But what if you need to enter it somewhere that doesn't support it? A physical device, a VM that doesn't allow copy and paste, a mobile app without support for copy/paste or password managers...

All those scenarios happen for me every couple of weeks and it's what's keeping me from using really long passwords with high complexity.

Re: Bitwarden design flaw: Server side iterations

#36
post #29
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…

As of now, your link is fine (though the comment is probably still editable), and I believe you have the best of intetions but Note: It's not a great idea to click a link to something like Bitwarden, since a phishing domain could be used.

Fair enough, I added navigation instructions.

Re: Bitwarden design flaw: Server side iterations

#37
post #8

Earlier quoted context omitted.

You can self host bitwarden, using either their implementation or open source vaultwarden

Exactly, BitWarden is not as shit as others like LastPass or 1Password.

Have you seen 1Passwords security design? I am not an expert, but wanted to hear from someone is.

Re: Bitwarden design flaw: Server side iterations

#38
post #15

Earlier quoted context omitted.

The number of iterations scales linearly with the cost of brute-forcing. The cost scales exponentially with the length of the password, assuming a random password (stops scaling when you reach the hash size I think). Both are important because you can't freely increase the password length, they become more annoying to enter and remember.

If your first two statements are correct I can't see how the third can't be. If we choose our password from only ~24 chars then you can get the same effect of 100K iterations form just 4 more characters, or ~1 more dictionary word. That doesn't seem excessive

10ms (or whatever) of computer time is a lot cheaper than 2 seconds of mine

Re: Bitwarden design flaw: Server side iterations

#39
post #15

Earlier quoted context omitted.

The number of iterations scales linearly with the cost of brute-forcing. The cost scales exponentially with the length of the password, assuming a random password (stops scaling when you reach the hash size I think). Both are important because you can't freely increase the password length, they become more annoying to enter and remember.

If your first two statements are correct I can't see how the third can't be. If we choose our password from only ~24 chars then you can get the same effect of 100K iterations form just 4 more characters, or ~1 more dictionary word. That doesn't seem excessive

Increasing the iterations is basically free (up to the point where it requires human-noticable amounts of time to calculate), so there's no need to require 4 more characters.

Also, teaching users enough of this to do it well is basically impossible. You have to have a threat model that includes your users being fairly shit at passwords. Especially when your product is solving the problem of users being shit at passwords.

Re: Bitwarden design flaw: Server side iterations

#40
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…

Can someone Eli5 iterations in this context?
Post reply on HN