6 ms·

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 u

by fuoqi 6y ago

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_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr...

est31 6y ago
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.
- tmikaeld 6y ago
  Then make it a users choice?
  - onli 6y ago
    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.
    - CyberRage 6y ago
      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.
      - selykg 6y ago
        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?
        cwyers 6y ago
        Yes. Part of the value prop of these services is they have experts who are better qualified to make these decisions than I am.
        ohyeshedid 6y ago
        It's a poor approach for multiple reasons. Like being the origin of downgrade attacks.
        tmikaeld 6y ago
        If the default is the downgrade, what have you lost if there's not upgrade path in the first place? nothing!
        CyberRage 6y ago
        There's no issue with that. layman users won't modify these settings while advanced users will be warned. You're thinking wrong.
        tmikaeld 6y ago
        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.
- fuoqi 6y ago
  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 login is negligible. And for other use-cases you can let users choose.
  - CyberRage 6y ago
    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.
    - fuoqi 6y ago
      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.
      - CyberRage 6y ago
        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
        fuoqi 6y ago
        Deriving two separate keys does indeed improve the situation, but still not ideal, see: https://news.ycombinator.com/item?id=26230259 https://news.ycombinator.com/item?id=26230259
  - 6y ago
- Dylan16807 6y ago
  > 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?
- D-Nice 6y ago
  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.
dchest 6y ago
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 https://news.ycombinator.com/item?id=25522361 As for Bitwarden's implementation: it doesn't send the password to the server, it sends, basically, a PBKDF2 hash, which is different from the one used for encryption. The leaked hash can't be used to decrypt the database unless it's bruteforced. However, the protocol is not ideal, there's a weakness that I wrote about here: https://dchest.com/2020/05/25/improving-storage-of-password-encrypted-secrets-in-end-to-end-encrypted-apps/ https://dchest.com/2020/05/25/improving-storage-of-password-... AFAIK, 1Password uses SRP with PBKDF2 for verifier.
- fuoqi 6y ago
  >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 https://news.ycombinator.com/item?id=26230200
  - CyberRage 6y ago
    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
D-Nice 6y ago
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.

by fuoqi 6y ago

est31 6y ago

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.

tmikaeld 6y ago
Then make it a users choice?
- onli 6y ago
  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.
  - CyberRage 6y ago
    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.
    - selykg 6y ago
      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?
      - cwyers 6y ago
        Yes. Part of the value prop of these services is they have experts who are better qualified to make these decisions than I am.
      - ohyeshedid 6y ago
        It's a poor approach for multiple reasons. Like being the origin of downgrade attacks.
        tmikaeld 6y ago
        If the default is the downgrade, what have you lost if there's not upgrade path in the first place? nothing!
      - CyberRage 6y ago
        There's no issue with that. layman users won't modify these settings while advanced users will be warned. You're thinking wrong.
        tmikaeld 6y ago
        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.
fuoqi 6y ago
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 login is negligible. And for other use-cases you can let users choose.
- CyberRage 6y ago
  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.
  - fuoqi 6y ago
    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.
    - CyberRage 6y ago
      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
      - fuoqi 6y ago
        Deriving two separate keys does indeed improve the situation, but still not ideal, see: https://news.ycombinator.com/item?id=26230259 https://news.ycombinator.com/item?id=26230259
- 6y ago
Dylan16807 6y ago
> 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?
D-Nice 6y ago
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.

dchest 6y ago

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 https://news.ycombinator.com/item?id=25522361 As for Bitwarden's implementation: it doesn't send the password to the server, it sends, basically, a PBKDF2 hash, which is different from the one used for encryption. The leaked hash can't be used to decrypt the database unless it's bruteforced. However, the protocol is not ideal, there's a weakness that I wrote about here: https://dchest.com/2020/05/25/improving-storage-of-password-encrypted-secrets-in-end-to-end-encrypted-apps/ https://dchest.com/2020/05/25/improving-storage-of-password-... AFAIK, 1Password uses SRP with PBKDF2 for verifier.

fuoqi 6y ago
>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 https://news.ycombinator.com/item?id=26230200
- CyberRage 6y ago
  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

D-Nice 6y ago

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.