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

21–30 of 97 posts

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

#21

Post by user5994461 »

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 a researcher's wet dream, ideal by some algorithmic definitions, yet it has no benefits in practice.

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

#22

Post by sneak »

Harvesterify wrote: post #16
sneak wrote: post #10

Earlier quoted context omitted.

In theory, absolutely. In practice, bitwarden's server limits the max iteration count on a user account to something that remains insecure. They refuse to fix it. https://github.com/bitwarden/server/issues/589

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.

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

#23

Post by SAI_Peregrinus »

dheera wrote: post #2

What's wrong with PBKDF2-SHA256? I use PBKDF2-HMAC-SHA256 for an almost-stateless password manager.

It's not memory-hard. That makes it much, much faster on GPUs than CPUs, which tends to mean it's much faster for attackers than legitimate users. It's also likely vunlerable to side-channel attacks, since nothing in its design tries to resist those. It's not broken by any means, and still vastly better than just a salted cryptographic hash, but it's not as good as Argon2id.

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

#24

Post by tmikaeld »

est31 wrote: post #20
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_…

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?

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

#25

Post by sneak »

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"?

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

#26

Post by px43 »

user5994461 wrote: post #13
kaiju0 wrote: post #6

Earlier quoted context omitted.

SHA and MD are fast hashers. You want slow hashers for password security like b-crypt and s-crypt.

PBKDF2 is a slow algorithm specifically created for password hashing. It's in the same family as bcrypt and scrypt.

> 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 algorithms like bcrypt and scrypt are vulnerable to.

PBKDF2 is essentially a linear slowdown, which is effectively pointless these days.

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

#27

Post by user5994461 »

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…

A $2k computer can do billions of hashes a second. 2^30

You're off by about 20 orders of magnitude (the joy of binary exponents).

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

#28

Post by fuoqi »

est31 wrote: post #20
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_…

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 login is negligible. And for other use-cases you can let users choose.

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

#29

Post by user5994461 »

px43 wrote: post #26
user5994461 wrote: post #13

Earlier quoted context omitted.

PBKDF2 is a slow algorithm specifically created for password hashing. It's in the same family as bcrypt and scrypt.

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

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

#30

Post by e12e »

sneak wrote: post #4
henriquez wrote: post #3

If it's not broke, don't fix it. The underlying hasher is most important anyway. Crappy passwords will always be susceptible to rainbow attacks.

No, not with salt and a high enough iteration count, they won't be.

I think gp is a bit off - weak passwords will be vulnerable to a dictionary attack - even if reasonably salted. But won't be vulnerable to rainbow attacks in any meaningful sense (assuming sensible salt/hash/iterations).
Post reply on HN