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

81–90 of 97 posts

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

#81

Post by infogulch »

User-defined passwords are a bad choice for an encryption KDF. I'm not disagreeing with sibling xxpor's tl;dr that worse is better here; getting everyone on password managers would be a huge net win for personal security. But debating the choice of KDF is missing the elephant in the room: that user passwords simply lack enough entropy for use as secure key material. It's like debating which kind of paper you should use to repair a huge hole in your bunker with a paper mache.

That said, asking the user to manually type full-size generated keys between devices is simply a nonstarter.

But what if the user stored their passwords in a private Matrix room? Matrix' solution to sharing encryption keys between devices is by being the communication channel by which users approve new devices from existing devices; upon approval the room's encryption key is sent to the new device encrypted using the new device's public key. That is, the room key can only ever be seen by the devices themselves. (I think this is a reasonable summary of encryption in Matrix, please correct me if I'm mistaken.) This is basically using a Matrix room as a general distributed, encrypted data store. Thoughts?

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

#82

Post by goalieca »

user5994461 wrote: post #72
CyberRage wrote: post #37

Earlier quoted context omitted.

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

> You can't compare plain SHA256 with PBKDF2.

But you can. It’s literally just N times the hash. Typically the number of iterations is chosen to be somewhat slow on the server that derives it. But a specially designed rig can execute this with extreme parallelism and speed.

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

#83

Post by alserio »

SAI_Peregrinus wrote: post #23
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.

If I may ask a question: how would I use a memory hardened algorithm on a server if the server ram can't scale infinitely? It seems to me that a few concurrent user logins would effectively DOS the server for any reasonable configuration of argon2

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

#84

Post by Kuinox »

ufmace wrote: post #80
tubbyjr wrote: post #76

Earlier quoted context omitted.

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.

ASIC doesn't work well when a lot of RAM is required.

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

#85

Post by tialaramex »

fmajid wrote: post #47
nijave wrote: post #39

Earlier quoted context omitted.

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.

My good bank (First Direct) gave me a physical OTP code generator, so I need a PIN and the physical device to get codes which are needed to log in. Once upon a time read-only activities like "Check balance" didn't need a code, but they got rid of that functionality because it's presumably a security risk with little benefit.

The same physical device constructs confirmation codes (proving I know the PIN) for specific inputs like if I want to send money somewhere I've never sent it before or a much great amount of money than usual.

However unlike U2F or its modern successor WebAuthn that's still in principle vulnerable to phishing, if thirstdirect.example pretends to be firstdirect.example and I don't notice, the codes I give to the wrong site work on the real one.

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

#86

Post by tialaramex »

sneak wrote: post #78
masterofmisc wrote: post #34

Earlier quoted context omitted.

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.

U2F is (as its full name "Universal Second Factor" would suggest) specifically only a second factor, it doesn't make sense as your first or only factor.

WebAuthn can replace the entire authentication, because it can perform multi-factor authentication locally and then send a claim to have done so, optionally backed by attestation from a vendor saying they promise the multi-factor authentication is done by their product. For example an iPhone can have one press sign-in to web sites or apps using this technology.

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

#87

Post by xxpor »

vinay_ys wrote: post #17
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…

What do you use for 2FA tokens?

YubiKeys (4 I think? It's been a while since I bought them)

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

#88

Post by tialaramex »

A lot of the sub-threads seem to have decided to talk about using PBKDF2-SHA256 as a password hash like crypt(), which actually isn't what the linked report is about. PBKDF2, as its name suggests, is a key derivation function. We can use these as password hashes, and people do, but we can also use them to turn any human memorable password (like "stonks", "S&SMBMBbc&wem" or "fzg76@PRU385!") into a nice 128-bit or 256-bit symmetric encryption key and that's what they're doing in tools like Bitwarden or 1Password.

In this role, you very much have a practical option to just pick a decent password. "stonks" is not a good password, the second one is a Rhianna lyric ("... but chains and whips excite me") but the third one is a pretty obscure reference and it's neither likely that your adversary would "guess" it nor that the sort of brute force attacks envisioned would hit this random looking 13 character password.

Anyway, even as a password hash I've made the argument previously that stronger hashes only marginally improve things, far too many of your users will pick "stonks" or if you insist on eight characters maybe "stonks!!" and even if you have Argon2 tuned way up the attacker can reverse that because it's too obvious. If your users picked unique random passwords (as they might with tools like Bitwarden or 1Password, even though I personally use zx2c4's pass) then it doesn't matter if you use a terrible hash like some turn of the century PHP forum using MD5, because that's still safe with such passwords.

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

#89

Post by upofadown »

goalieca wrote: post #36
user5994461 wrote: post #29

Earlier quoted context omitted.

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

Note that we are talking about a single RSA operation. So attacks that require repeated trials are not relevant here.

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

#90

Post by luis8 »

Dylan16807 wrote: post #69
luis8 wrote: post #53

Earlier quoted context omitted.

Is sharing you password length wise? Knowing the # of chars you have reduced the number of iterations needed to complete a brute force attack. 255! vs 255! / (255 - 30)! My math could be off though, i haven't work with factorials since i was in the university

I don't think you want a factorial involved. With unknown size, cracking 30 characters takes time proportional to n^30 + n^29 + n^28 etc. Cracking just 30 is proportional to n^30. The difference is negligible. A percent or two.

My bad, I was thinking in permutations but those does not allow repeated entries. It make sense now, like you said the difference is negligible.
Post reply on HN