Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we are still using PBKDF2-SHA256 despite being aware of its limitations

github.com

Post reply on HN
Print view View original

31–40 of 97 posts

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#31

Post by onli »

tmikaeld wrote: post #24
est31 wrote: post #20

Earlier quoted context omitted.

I think that's the problem here: Bitwarden hashes the passwords on the client side but it runs on various client devices, some more powerful than others, and others not able to run efficient Argon2 implementations.

Then make it a users choice?

How? Seriously interested. This is cross-plattform software. How do you change that from PBKDF2-SHA256 to Argon in a way that still lets you use your desktop PC as well as your 4 year old budget Android device? And then support user configuration on top of that? Same about raising iterations.

The submitted github comment also makes that point, this is actually hard to do.

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#32

Post by CyberRage »

fuoqi wrote: post #28
est31 wrote: post #20

Earlier quoted context omitted.

I think that's the problem here: Bitwarden hashes the passwords on the client side but it runs on various client devices, some more powerful than others, and others not able to run efficient Argon2 implementations.

Ah, I thought it's a JS library used on a server side. But am I correct that they still pass the derived master-key to server side in a plain form? Citing the OP: >Sure, you might tolerate a longer unlock time, but is the security gain really worth the cost to your battery? I think the battery concern is over-blown. How often do you login into a service? I think that for typical use-cases, amortized battery-cost of a…

These cloud based solutions perform hashing+salting+KDFing locally and then add additional compute cost on the cloud level.

I don't see any issues with that.

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#33

Post by bscphil »

henns wrote: post #15

I think this misses the point: we should be doing everything we can to deprecate PBKDF2 because of the big differences between what a specialized attacker can do vs. the defender. As a rough estimate: a $2k bitcoin miner can do 2^45 SHA-256 hashes/sec whereas your $2k laptop can do 2^16 hashes/sec; the attacker has ~a billion x advantage over you that can be multiplied based on their funding. At that point, doing eve…

This is interesting because the OP claims that this is exactly the reason they use PBKDF, because there aren't "highly optimized implementations [of other crypto algorithms] for all platforms":

> What is crucial here is that we don't want to have the defender stuck with a slow implementation of something that the attacker will have a highly optimized implementation for.

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#34

Post by masterofmisc »

sneak wrote: post #25
xxpor wrote: post #12

My threat model isn't a directed attack, it's DB dumps with unhashed or unsalted passwords from random websites. I want to use a unique password on every site, and password managers provide a convenient way of doing that. Even if every BW vault leaked, if it takes half a day to run through 8 a-zA-Z0-9, it's not practical to do that for every vault. On the other hand, if I'm being targeted, even increasing that to a m…

> Every "critical" site I use also supports u2f 2fa, which I've turned on. What US bank do you use that supports U2F, or do you not include banking in "critical"?

I don't know about the US but Barclays in the UK has had multi-factor authentication for years now. Is that not the case in the US?

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#35

Post by dchest »

fuoqi wrote: post #19

The model of hashing user plaintext passwords on server-side is itself a deeply flawed one. User password and master keys derived out of it should NEVER leave user-controlled computer. For authentication password-authenticated key agreement protocols [0] should be used, anything but it means that service does not treat user security as a high enough priority. [0]: https://en.wikipedia.org/wiki/Password-authenticated_…

PAKE still require storing verifier on the server, which is basically a password hash. There's no significant difference in security between PAKE and a home-grown implementation that Bitwarden uses with respect to password hash leaks from the server database. See my comment here: https://news.ycombinator.com/item?id=25522361

As for Bitwarden's implementation: it doesn't send the password to the server, it sends, basically, a PBKDF2 hash, which is different from the one used for encryption. The leaked hash can't be used to decrypt the database unless it's bruteforced. However, the protocol is not ideal, there's a weakness that I wrote about here: https://dchest.com/2020/05/25/improving-storage-of-password-...

AFAIK, 1Password uses SRP with PBKDF2 for verifier.

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#36

Post by goalieca »

user5994461 wrote: post #29
px43 wrote: post #26

Earlier quoted context omitted.

> PBKDF2 is a slow algorithm specifically created for password hashing. Yeah, over 20 years ago. It's woefully out of date by modern standards. PBKDF2 doesn't even attempt memory hardness, so there are whole classes of attacks on later generation slow hashing algorithms that don't even apply to PBKDF2 because of how old it is. Argon2 is extremely resistant to Time-Memory-Trade-Off (TMTO) attacks, which older algorith…

Math doesn't age. Cheers. bcrypt and scrypt, the successors to PKDF2, are both more than a decade old. RSA is half a century old and it's still up to date by modern standards. In fact nobody has came up with anything better. Edit: Actually, bcrypt might be as far as 1999, possibly older than PBKDF2.

> RSA is half a century old and it's still up to date by modern standards. In fact nobody has came up with anything better.

RSA is currently a minefield of gotchas and few security companies even get it right. Just generating a good key is actually a very difficult task. It is also very computationally slow and has many practical issues for the level of security it provides.

There are many superior replacements in both pqc and elliptic spaces. I would take EdDSA over rsa-pss any day of the week.

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#37

Post by CyberRage »

user5994461 wrote: post #21
goalieca wrote: post #8

Pbkdf2 itself is not the best for the same reasons why sha256 was listed. I do agree that argon2 is better.

PBKDF2 and SHA256 are fine for all use cases and have libraries available in all languages. argon2 has nothing better to offer. Practically there are 3 argon variants to chose from and they all require careful configuration. It's pretty hard to start with, assuming you can find libraries for it in the first place, last I checked it wasn't commonly supported. It's a perfect example of theory versus practice. Argon is…

Are you serious? Even something that would be considered "bad" argon2 set-up is far better than anything that is based on SHA256.

Modern GPUs and ASICs can perform millions of SHA operations per second, even with a poorly configured Argon2, you reduce that massively.

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#38

Post by the_mitsuhiko »

sneak wrote: post #22
Harvesterify wrote: post #16

Earlier quoted context omitted.

Use a longer and more complex master password. You're welcome.

You're the sixth person to reply to me with this "advice". My own password is 30 characters and I self-host bitwarden_rs, patched to permit a higher KDF iteration count. This has nothing to do with my usage.

Evidently there is no problem then.

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#39

Post by nijave »

sneak wrote: post #25
xxpor wrote: post #12

My threat model isn't a directed attack, it's DB dumps with unhashed or unsalted passwords from random websites. I want to use a unique password on every site, and password managers provide a convenient way of doing that. Even if every BW vault leaked, if it takes half a day to run through 8 a-zA-Z0-9, it's not practical to do that for every vault. On the other hand, if I'm being targeted, even increasing that to a m…

> Every "critical" site I use also supports u2f 2fa, which I've turned on. What US bank do you use that supports U2F, or do you not include banking in "critical"?

Banks might not support u2f but they pretty universally support some form of 2FA (I think certain things like PCI require it but not sure on exact regs)

It might not be quite as good but email 2FA behind U2F protected email gets you pretty close

Re: Why we are still using PBKDF2-SHA256 despite being aware of its limitations

#40

Post by CyberRage »

onli wrote: post #31
tmikaeld wrote: post #24

Earlier quoted context omitted.

Then make it a users choice?

How? Seriously interested. This is cross-plattform software. How do you change that from PBKDF2-SHA256 to Argon in a way that still lets you use your desktop PC as well as your 4 year old budget Android device? And then support user configuration on top of that? Same about raising iterations. The submitted github comment also makes that point, this is actually hard to do.

Offer the user the choice for other solutions with a performance penalty?

Choice is always better. for people who care\worry, they can change to something more resistant to cracking.

Post reply on HN