Live data from Hacker News

Bitwarden design flaw: Server side iterations

palant.info

41–50 of 264 posts

Re: Bitwarden design flaw: Server side iterations

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

The password in question here is the master password for your bitwarden account. Bitwarden can't remember that for you.

Re: Bitwarden design flaw: Server side iterations

#43
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?

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.

Re: Bitwarden design flaw: Server side iterations

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

BitWarden - The least shitty password manager!

Re: Bitwarden design flaw: Server side iterations

#46
Good to have the heads up. I just bumped my KDF iterations from 100000 to 600000.

One thing that is also worth mentioning for anyone nervous about their password security is that you can use a physical security key with the paid version of Bitwarden. I need to use a yubikey to log in to any new instance of Bitwarden and it's been working well.

Re: Bitwarden design flaw: Server side iterations

#47
Tangentially related: why would a password manager provide a configurable iteration count? This is a number whose purpose is fairly hard to understand for many people and yet it’s an important corner stone for password security, especially for those who do not grasp the concept of an iteration count.

This should absolutely be application managed and gradually increased over time.

Also: while I understand that FIPS is the reason why we are stuck with PBKDF2 in the case of the more enterprisy password managers, wouldn’t it still be FIPS compliant to do some scrypt or argon rounds on top as a means of not constantly having to update the PBKDF2 iteration count (assuming that scrypt and argon are more resilient to hardware brute-forcing)?

Re: Bitwarden design flaw: Server side iterations

#48
tl;dr rant, and not an exaggeration: the amount of time I've spent skimming these (edit to be nicer) exhausting comment threads about password managers has taken 10x the amount of time it took to use a pass-compatible or age-based password manager.

Okay, here we go, let me be explicit: there's a Venn diagram I imagine in my head of two circles - first is "password managers that require a web ui and browser integration", second is "password managers written in a language and with an overall complexity that I'm comfortable with".

For certainly-informed users, there's ZERO overlap in 2023. what's super fun is that this comment would get entirely different scores in yah, every 2 years for the past decade+ now. (think abour Rust circa 2021, 2019, 2017, I feel confident saying... for well most, opinion has been shifting in a certain direction).

luckily recently there is a tool which is,

1. rust-written

2. pass, pass-totp, and pass-tomb compatible

3. hasn't yet broken the CLI UX in nearly every release like another prominent "safe-lang" re-write of pass. that's all I'll say because it turned into a many-paragraph rant otherwise.

I'm trying so hard to watch myself here, but it's just not that hard. Let's imagine what needs to break for me to compromise your WV account versus what you'd need to compromise my public-hosted git-repo-backed yubikey-hardended-gpg-encrypted pass accounts. "I'll post mine if you post yours?"

Re: Bitwarden design flaw: Server side iterations

#49

Earlier quoted context omitted.

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.

Using a passphrase is the way to go. Easy to type, remember, and more secure.

Obligatory xkcd: https://xkcd.com/936/

Re: Bitwarden design flaw: Server side iterations

#50
post #37

Earlier quoted context omitted.

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.

It is not opensource, therefore you cannot self-host it, therefore you depend on a thirdparty.
Post reply on HN