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

71–80 of 97 posts

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

#71

Post by SloopJon »

bscphil wrote: post #33
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.

After a programmer changed PBKDF2 to use SHA512 instead of SHA-1, I asked whether it made sense to use SHA256 instead for this very reason. With SHA extensions on Intel (pretty rare, incidentally), and the cryptography extension on ARM, I wondered if SHA256 (with more iterations) might put defenders at less of a disadvantage relative to attackers than SHA512.

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

#72

Post by user5994461 »

CyberRage wrote: post #37
user5994461 wrote: post #21

Earlier quoted context omitted.

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.

You can't compare plain SHA256 with PBKDF2. PBKDF2 can take a million SHA operations to hash one password, if you configure it to (default is somewhere 10k to 1M).

If you were to leak your company database with 1 million customers and hashed passwords, there's some theoretical considerations to be made on resistance to GPU and ASIC cracking, practically you're in a pretty bad place whichever algorithm was used. ^^

P.S. Cryptography would have more weight if half the passwords weren't a variation of password2021 and hunter22.

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

#73

Post by ufmace »

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…

I think the important point is that Bitcoin mining hardware is much more specialized than that. The really crazy fast ASICs are hardwired to do SHA-256 hashes of Bitcoin block headers only and just increment the Bitcoin nonce before repeating. They can't be repurposed to crack password hashes.

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

#74

Post by user5994461 »

woliveirajr wrote: post #9

If I understood correctly, the points are: - using longer passwords (or salts) is better than increasing the number of rounds - having the same database on different devices (top-CPU x older cellphone) have impacts on the performance for the user but not for the attacker (as a powerful hardware will be used) Seems fair, for the average user. And the top user will prefer a longer password anyway.

First sentence is really the problem in the modern era.

The best most people can remember as a password, is some variations on common words and their date/place of birth.

Hence it doesn't matter what algorithms a database is using, computer will crack most passwords very effectively, provided with common words and minimal rules.

The only solution to secure against cracking is to have way more complicated passwords (very long), but people can't remember them.

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

#75

Post by contravariant »

bscphil wrote: post #46
contravariant wrote: post #43

Earlier quoted context omitted.

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

I've usually heard it being used to describe powers of 10. I'd be willing to accept 14 orders of magnitude since we're talking about powers of 2, but I still can't figure out where they got 20 from. Hence my question.

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

#76

Post by tubbyjr »

ufmace wrote: post #73
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…

I think the important point is that Bitcoin mining hardware is much more specialized than that. The really crazy fast ASICs are hardwired to do SHA-256 hashes of Bitcoin block headers only and just increment the Bitcoin nonce before repeating. They can't be repurposed to crack password hashes.

They may not be repurposable per se, but they are a great benchmark for what may be realistically achievable for cracking password hashes utilizing similar base algorithms.

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

#77

Post by user5994461 »

contravariant wrote: post #75
bscphil wrote: post #46

Earlier quoted context omitted.

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

I've usually heard it being used to describe powers of 10. I'd be willing to accept 14 orders of magnitude since we're talking about powers of 2, but I still can't figure out where they got 20 from. Hence my question.

One billion is 14 orders. We're talking billionS, that's a fair bit more (pun intended).

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

#78

Post by sneak »

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?

U2F is a specific type of 2FA/MFA.

They are not congruent.

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

#79

Post by goalieca »

user5994461 wrote: post #67
goalieca wrote: post #36

Earlier quoted context omitted.

> 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 bo…

RSA is extremely simple, it's just multiplications and powers. It can be reasonably explained to high school students. The tooling is mature and keys are trivial to generate safely with a openssl command. EdDSA is another level entirely. I don't know how you can recommend elliptic curve cryptography with a straight face if you think RSA is hard. P.S. It's a myth that EdDSA is faster. This depends on operation (signin…

Elliptic curves are also quite simple. Computing a public key boils down to point addition with a modulus.

The private key is a byte string and the quality of it only depends on the random generator. It’s trivially fast to generate 32 bytes of decent quality random numbers these days. There are many insecure rsa generation methods with weak criteria. Too many are fossilized in libraries and crypto cores. Rsa also has half a dozen padding schemes and most are now considered weak or vulnerable.

EC is generally considered much stronger for a much smaller key size.

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

#80

Post by ufmace »

tubbyjr wrote: post #76
ufmace wrote: post #73

Earlier quoted context omitted.

I think the important point is that Bitcoin mining hardware is much more specialized than that. The really crazy fast ASICs are hardwired to do SHA-256 hashes of Bitcoin block headers only and just increment the Bitcoin nonce before repeating. They can't be repurposed to crack password hashes.

They may not be repurposable per se, but they are a great benchmark for what may be realistically achievable for cracking password hashes utilizing similar base algorithms.

AFAIK, the base algorithms here are custom-fabricated ASICs. If your adversary can custom-fab ASICs to break hashes in your PW manager password in PBKDF2-SHA256, no reason they couldn't make one in whatever harder algorithm you could come up with.
Post reply on HN