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

41–50 of 97 posts

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

#41

Post by fuoqi »

CyberRage wrote: post #32
fuoqi wrote: post #28

Earlier quoted context omitted.

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.

The issue is that if an attacker can eavesdrop on a compromised authentication server, then it can record user's master-key and thus he will be able to impersonate user without issues until the password gets changed (i.e. the derived master-password is actually plays role of a password now). With PAKE this issue simply does not exist.

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

#42

Post by __s »

dheera wrote: post #2

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

Read the opening comment on the issue

It's reasonable to expect an attacker to have a SHA256 ASIC given Bitcoin making those a commodity

Potentially this can be offset if your server has https://en.wikipedia.org/wiki/Intel_SHA_extensions but if you're running on cell phones that's not there

See also https://bitcoin.stackexchange.com/questions/36253/what-minin...

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

#43

Post by contravariant »

user5994461 wrote: post #27
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).

I'm confused, 2^14 = 16384 is slightly more than 4 orders of magnitude, where did you get 20 from?

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

#44

Post by fuoqi »

dchest wrote: post #35
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, basi…

>PAKE still require storing verifier on the server, which is basically a password hash.

No, there is an important difference: leaking this verifier does not let an attacker to impersonate user at will. See my other message [0].

Is my understanding correct that you derive two keys from user password, one used for authentication and one for decrypting encrypted content which does not leave the user's computer? In that case, yes, it's somewhat better than the typical scenario, though I personally would still prefer if a proper PAKE was used for authentication. It may not apply to your service, but leaking encrypted data can still result in exposing certain meta-information, which may be important, so it's better to be extra-safe in such matters.

[0]: https://news.ycombinator.com/item?id=26230200

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

#45

Post by CyberRage »

fuoqi wrote: post #41
CyberRage wrote: post #32

Earlier quoted context omitted.

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.

The issue is that if an attacker can eavesdrop on a compromised authentication server, then it can record user's master-key and thus he will be able to impersonate user without issues until the password gets changed (i.e. the derived master-password is actually plays role of a password now). With PAKE this issue simply does not exist.

Nono. the master-key never leaves the device.

Via the master-key, the program derives(locally) the key to encrypted the data and a different secondary key for authentication against the server. without knowing the master-key you can't decrypt the vault even if you were able to trick the server into sending you the vault.

The vault is decrypted locally

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

#46

Post by bscphil »

contravariant wrote: post #43
user5994461 wrote: post #27

Earlier quoted context omitted.

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

I'm confused, 2^14 = 16384 is slightly more than 4 orders of magnitude, where did you get 20 from?

An "order of magnitude" has no precise numerical meaning, it depends on what base you're working in. If the log of the number in base b increases by 1, you've increased 1 order of magnitude with respect to that base. (I don't know why the parent said "20", my instinct is to say 14 orders of magnitude here.)

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

#47

Post by fmajid »

nijave wrote: post #39
sneak wrote: post #25

Earlier quoted context omitted.

> 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

Most support only SMS as security theater, which is worse than useless because it fosters a false sense of security.

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

#48

Post by selykg »

CyberRage wrote: post #40
onli wrote: post #31

Earlier quoted context omitted.

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.

As someone who worked in this field. Offering "options" when a vast majority of the user base don't even understand that their data is encrypted, is often a poor approach to take.

Users will forget their Master Passwords even and because they forgot them they will believe they've been "hacked" and blame you.

Users on Hacker News and similar sites where users actually understand the underlying technology to some degree are the exception, not the norm. Adding options does not help a vast majority of the user base and it complicates your codebase further. Imagine making that change and less than 1% of your users actually use that feature?

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

#49

Post by fuoqi »

CyberRage wrote: post #45
fuoqi wrote: post #41

Earlier quoted context omitted.

The issue is that if an attacker can eavesdrop on a compromised authentication server, then it can record user's master-key and thus he will be able to impersonate user without issues until the password gets changed (i.e. the derived master-password is actually plays role of a password now). With PAKE this issue simply does not exist.

Nono. the master-key never leaves the device. Via the master-key, the program derives(locally) the key to encrypted the data and a different secondary key for authentication against the server. without knowing the master-key you can't decrypt the vault even if you were able to trick the server into sending you the vault. The vault is decrypted locally

Deriving two separate keys does indeed improve the situation, but still not ideal, see: https://news.ycombinator.com/item?id=26230259

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

#50

Post by fmajid »

masterofmisc wrote: post #34
sneak wrote: post #25

Earlier quoted context omitted.

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

If it is TOTP/HOTP based rather than U2F (6-digit codes), it is vulnerable to real-time spoofing.
Post reply on HN