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

51–60 of 97 posts

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

#51

Post by cwyers »

selykg wrote: post #48
CyberRage wrote: post #40

Earlier quoted context omitted.

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

Yes. Part of the value prop of these services is they have experts who are better qualified to make these decisions than I am.

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

#52

Post by CyberRage »

fuoqi wrote: post #44
dchest wrote: post #35

Earlier quoted context omitted.

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…

Encryption\Decryption are done locally. the server has no clue what your master-key is, all it knows here's a blob of data you need to store, here's my "ID"(The secondary key generated which is different from the encryption key and also relies on the master-key and other parameters).

When retrieving the vault, the program will generate the secondary key, provides it to the server(You can add 2FA btw), the server sees that indeed it matches one of the ID's and sends you back the encrypted vault. decryption is done locally.

I don't see any issue with this process, maybe you care to point the attack vector\scenario

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

#53

Post by luis8 »

sneak wrote: post #22
Harvesterify wrote: post #16

Earlier quoted context omitted.

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.

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

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

#54

Post by ohyeshedid »

selykg wrote: post #48
CyberRage wrote: post #40

Earlier quoted context omitted.

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

It's a poor approach for multiple reasons. Like being the origin of downgrade attacks.

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

#55

Post by dheera »

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…

> essentially a linear slowdown

Why does it have to be linear? Just use 1M irritations today, 2M irritations next year, 4M irritations the year after that, and you'll have an exponential version of it.

You can even take your 1M irritated hashes from this year and execute an additional 1M more irritations on them to update them to 2M irritations when you want to upgrade.

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

#56

Post by demosito666 »

fuoqi wrote: post #28
est31 wrote: post #20

Earlier quoted context omitted.

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…

> But am I correct that they still pass the derived master-key to server side in a plain form?

No. Master key doesn't leave client machine, only its hash is transmitted over the network. See dchest's link above.

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

#57

Post by CyberRage »

selykg wrote: post #48
CyberRage wrote: post #40

Earlier quoted context omitted.

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

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

You're thinking wrong.

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

#58

Post by fuoqi »

CyberRage wrote: post #52
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…

Encryption\Decryption are done locally. the server has no clue what your master-key is, all it knows here's a blob of data you need to store, here's my "ID"(The secondary key generated which is different from the encryption key and also relies on the master-key and other parameters). When retrieving the vault, the program will generate the secondary key, provides it to the server(You can add 2FA btw), the server sees…

Leaking the secondary key will allow an attacker to impersonate user at any time and to continuously retrieve the encrypted vault. As I've said, it may not be important for a password storage, but in more sophisticated applications continuous access to an encrypted vault may leak important meta-information (e.g. number of files, their size, time of creation, etc.).

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

#59

Post by dchest »

fuoqi wrote: post #44
dchest wrote: post #35

Earlier quoted context omitted.

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…

(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 useless.) Their protocol though uses a strong key in addition to password, making password bruteforcing from the verifier impossible.

I'm not against PAKE — the biggest benefit is that you don't have to create your own protocol and make mistakes. What I'm saying is that for such use cases its security benefits compared to other protocols are negligible.

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

#60

Post by CyberRage »

fuoqi wrote: post #58
CyberRage wrote: post #52

Earlier quoted context omitted.

Encryption\Decryption are done locally. the server has no clue what your master-key is, all it knows here's a blob of data you need to store, here's my "ID"(The secondary key generated which is different from the encryption key and also relies on the master-key and other parameters). When retrieving the vault, the program will generate the secondary key, provides it to the server(You can add 2FA btw), the server sees…

Leaking the secondary key will allow an attacker to impersonate user at any time and to continuously retrieve the encrypted vault. As I've said, it may not be important for a password storage, but in more sophisticated applications continuous access to an encrypted vault may leak important meta-information (e.g. number of files, their size, time of creation, etc.).

As I've mentioned, when retrieving the vault other parameters need to match like Account name, Email etc.

You can add 2FA to the authentication process.

All metadata is obviously encrypted, the data is just a single blob. you maybe could try to guess the number of entries based on size but that's too dynamic as well.

These products were attacked before, decrypting the vault wasn't how they were attacked.

It was with bugs\vulnerabilities within the browser extensions that lead to data leaks. something else entirely.

Post reply on HN