Live data from Hacker News

Bitwarden design flaw: Server side iterations

palant.info

261–264 of 264 posts

Re: Bitwarden design flaw: Server side iterations

#261

Earlier quoted context omitted.

> Not all books in all languages ever published are "somewhere out there". I mean, they mostly are or can be. What's the point on relying on "nobody happened to catalog the book I copied my passphrase from"? Are you going to check every week that nobody uploaded it to an archive site? There's easier schemes that don't rely on that.

For smaller languages the steps would be: - Somebody would have to digitize an old book without mistakes. - Somebody would have to publish it online. - Somebody would have to scrape and archive that. - Somebody would have to transliterate it to Latin script. - That transliteration would also have be the same transliteration I'm using. It's unlikely it will be done for a lot of languages. > There's easier schemes that…

> Remembering random words is hard. This is how we got into this in the first place.

It's really not. You just make a story out of it. My memory is quite crap, I'm still able to remember the ~3 passphrases I actually need, and I'm able to rotate them as required.

Re: Bitwarden design flaw: Server side iterations

#262

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, 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. That's the theory of passwords, but it has been demonstrated that most people simply can't manage their passwords. I have about 600 passwords stored in my password manager. Without a password manager, I'd have to reuse passwords (either par…

Not that it matters much in practice, but a 60-character uniformly random password is overkill. Given that a 128 bit key is considered secure and one may occasionally need to type a password due to technical constraints, 21 randomly selected characters from a 72-character alphabet is enough. Double it if you want to target 256-bit security, but the threat model here doesn’t really support that. Are you expecting a large-scale quantum computer attack on the HN password hash database?

Re: Bitwarden design flaw: Server side iterations

#264

Other than the low amount of default iterations (at least compared to the OWASP recommendation [0]) the article doesn't explain why the server-side hashing is "useless" and what the design flaw actually is. Am I missing something? [0]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

I disagree with the article that server-side iterations in this case are useless. They are used for access control.

Bitwarden's API likely doesn't permit anybody to access the encrypted blobs of anybody. You have to authenticate at the server to be able to access your blob. Since the iterations might be low for producing the master key and therefore the master password hash, the server must treat the master password hash as just another password and therefore iterate the hash quite often (100,000x).

Assuming no malicious insider or an outside attacker gets their hands on the encrypted blobs this is the most important attack prevention.

Post reply on HN