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

61–70 of 97 posts

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

#61

Post by tmikaeld »

CyberRage wrote: post #57
selykg wrote: post #48

Earlier quoted context omitted.

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

There's no issue with that. layman users won't modify these settings while advanced users will be warned. You're thinking wrong.

Agreed, defaults are the norm and then the advanced settings are layered. Even so, explaining and showing the differences visually or with video is possible. I don't agree with treating people as babies when it comes to tech.

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

#62

Post by fuoqi »

dchest wrote: post #59
fuoqi wrote: post #44

Earlier quoted context omitted.

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

(Not my service, I'm just a random commenter) The same happens with PAKE during registration, where the user will need to provide the verifier. Since everything happens over TLS anyway, and hopefully, with pinning (in apps), this is not a huge concern. I haven't checked Bitwarden, but even though 1Password uses SRP, the initial registration happens in a browser. (PAKE inside a browser with JavaScript is even more use…

>The same happens with PAKE during registration, where the user will need to provide the verifier.

In a typical PAKE, generated challenge depends on random values generated by both server and user, so if at least one of them is not controlled by an attacker, the generated challenge will be different each time. So leaking the verifier or eavesdropping on previous logins does not help an attacker to impersonate user in any way.

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

#63

Post by dchest »

fuoqi wrote: post #62
dchest wrote: post #59

Earlier quoted context omitted.

(Not my service, I'm just a random commenter) The same happens with PAKE during registration, where the user will need to provide the verifier. Since everything happens over TLS anyway, and hopefully, with pinning (in apps), this is not a huge concern. I haven't checked Bitwarden, but even though 1Password uses SRP, the initial registration happens in a browser. (PAKE inside a browser with JavaScript is even more use…

>The same happens with PAKE during registration, where the user will need to provide the verifier. In a typical PAKE, generated challenge depends on random values generated by both server and user, so if at least one of them is not controlled by an attacker, the generated challenge will be different each time. So leaking the verifier or eavesdropping on previous logins does not help an attacker to impersonate user in…

Right, the verifier can't be used to impersonate the user, but can be used to verify password guesses offline.

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

#64

Post by Dylan16807 »

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.

> some more powerful than others, and others not able to run efficient Argon2 implementations.

Like what? It looks like personally my phone is 4x slower than my desktop. So if I calibrate for one or two seconds on my phone, the security should be pretty acceptable. Do I need to worry about devices much slower than that?

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

#65

Post by D-Nice »

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 completely agree on server-side derivation being flawed, which is why I made SrsPass, which derives child passwords for you client side, you can use across accounts, and ensures even if you end up making a password on a shitty site that plaintexts your credentials, it won't compromise your master key, as it's 128-bit salted.

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

#66

Post by throwaway744678 »

luis8 wrote: post #53
sneak wrote: post #22

Earlier quoted context omitted.

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.

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

It's a trick. OP's password is actually 29 chars long, but the attacker will now start at 30 characters, and never brute force the actual password. Nicely played.

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

#67

Post by user5994461 »

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…

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 (signing vs verification) and key size.

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

#68

Post by D-Nice »

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.

Try srspass.com which runs argon2id in the browser. Takes about 3 seconds on my ARM phones for the unlock, which uses quite heavy argon2id parameters, above the recommended memory and iterations.

I don't think a 3s wait for a session, for greater security, and that on an unoptimized device is going to be breaking UX.

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

#69

Post by Dylan16807 »

luis8 wrote: post #53
sneak wrote: post #22

Earlier quoted context omitted.

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.

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.

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

#70

Post by [deleted] »

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

[deleted]
Post reply on HN