5 ms·

The article suggests that hashing (PBKDF2) is done client-side only, and that LastPass stores this hash directly. If true, this is very bad. However, LastPass

The article suggests that hashing (PBKDF2) is done client-side only, and that LastPass stores this hash directly. If true, this is very bad. However, LastPass claims that PBKDF2 is also used server side: > We then take that value, and use a salt (a random string per user) and do another 100,000 rounds of hashing, and compare that to what is in our database. https://blog.lastpass.com/2015/06/lastpass-security-notice/ https://blog.lastpass.com/2015/06/lastpass-security-notice/ While it's true that the client-side hashing means that LastPass never sees your plaintext password, the first hash effectively becomes the password. Then it's on LastPass to treat it as such, which they claim to do by hashing it again. Edit: another link describing the use of PBKDF2: https://support.logmeininc.com/lastpass/help/about-password-iterations-lp030027 https://support.logmeininc.com/lastpass/help/about-password-...

42jd 5y ago
When I was doing some research into building an app that encrypted data similar to these cloud password managers, I encountered OPAQUE[1] which seems to be the ideal way to perform authentication and securing a master encryption key. It is an asymmetric PAKE that also has a step for providing a salt. This removes the need to do what LastPass does with treating the first hash as a password. There is a great article from Cloudflare on how it works[2], and a working implementation of the spec in rust[3]. [1]: https://github.com/cfrg/draft-irtf-cfrg-opaque https://github.com/cfrg/draft-irtf-cfrg-opaque [2]: https://blog.cloudflare.com/opaque-oblivious-passwords/ https://blog.cloudflare.com/opaque-oblivious-passwords/ [3]: https://github.com/novifinancial/opaque-ke https://github.com/novifinancial/opaque-ke
8organicbits 5y ago
I wish there was a good way to implement this sort of double hashing in web apps. Doing the extra salted hash client side ensures that the value the server sees is globally unique, even when the user is reusing passwords across sites. Unfortunately the only way I know how to implement that is to have the server send JS down to the browser that instructs it to perform the hashing. For certain types of compromises server side, the attacker would just modify the JS to get the unhashed password. I'd also need to fall back to pure JS hashing for old browsers (5% users?), so there's a UX concern if I perform lots of rounds. I kind of wish there was a different password HTML field that could run the client side hashing without JS, so the browser would manage that. Ideally using different UX so the user understands they are using a "safe" password field. The end result would be to deny access to the raw password, which is likely reused on multiple sites.
- faeyanpiraat 5y ago
  But then malware on the user’s machine could catch that password. There is no 100% solution to this.
  - 8organicbits 5y ago
    Different problems need different solutions. I don't think I've ever seen a solution that solves 100% of all problems. This doesn't stop me from trying to improve security where I see opportunity.
  - lemarchr 5y ago
    Malware on the user's machine could catch the password in either case.
- necovek 5y ago
  Everything you explain points at no need to do client side hashing: what exact attack vector would be stopped by having it? (The only thing you bring up is reuse of passwords, but then you explain how that would be easily exploited if server was compromised, and it's even easier if client is) I would imagine most developers unfamiliar with encryption would assume that client hashing is sufficient and not bother with server side hashing which is the only one that ensures privacy in case of compromise on the server side (nothing really stops client side compromise).
  - sixothree 5y ago
    I assumed the point would be to store all of the salt values ever used server side and never allow reuse of a salt. That way if the hash is captured but has already been used then it is useless.
- kodah 5y ago
  WASM will do what you want. You can certainly have client side JS produce a hash using some other credential as the salt and then encrypt the information server side. What you really lose is the ability to do low cost comparison, because most password hashing is done deterministically. Instead you would need to retrieve the record, decrypt with the server side key, and finally compare.
stingraycharles 5y ago
Which to me begs the question: then why hash client-side at all? What are the threats it protects against?
- foobiekr 5y ago
  Hashing client side has a non-cryptographic benefit of making all passwords a fixed length. This, in turn, helps avoid accidents with bcrypt misuse.
- palant 5y ago
  The client-side hashing is actually the part that keeps your master password a secret, from everyone including LastPass yourself. This makes sure that LastPass cannot decrypt your passwords despite them being stored there. The server-side part on the other hand is severely misimplemented and not much good to anyone. This is one of the issues I’ve written about here: https://palant.info/2018/07/09/is-your-lastpass-data-really-safe-in-the-encrypted-online-vault/ https://palant.info/2018/07/09/is-your-lastpass-data-really-...
- SavantIdiot 5y ago
  From what I understand: you still need the master password locally to decrypt the individual passwords. A hash won't provide that. All you're doing here is logging into LastPass.
- chrisfosterelli 5y ago
  This sort of scheme is common so that you do not have to share the encryption key with the provider. You derive two keys from your plaintext password: one used for authentication and one used for encrypting / decrypting the blob. This way, Lastpass can authenticate you without having to see the key to decrypt your data. Not sure the specifics of how lastpass implements this but this is a really common approach for end-to-end encrypted apps.
  - necovek 5y ago
    I wouldn't say it's so you don't have to share the encryption key with your provider (you achieve that with a separate encryption key), but rather so you can use a single memorable secret for both login to the provider and local encryption. As in, the idea is that it is used to save you from having two secrets which might be more or less easy/hard to remember. It's a UX improvement (which might be a security imorovement on average too).

42jd 5y ago

When I was doing some research into building an app that encrypted data similar to these cloud password managers, I encountered OPAQUE[1] which seems to be the ideal way to perform authentication and securing a master encryption key. It is an asymmetric PAKE that also has a step for providing a salt. This removes the need to do what LastPass does with treating the first hash as a password. There is a great article from Cloudflare on how it works[2], and a working implementation of the spec in rust[3]. [1]: https://github.com/cfrg/draft-irtf-cfrg-opaque https://github.com/cfrg/draft-irtf-cfrg-opaque [2]: https://blog.cloudflare.com/opaque-oblivious-passwords/ https://blog.cloudflare.com/opaque-oblivious-passwords/ [3]: https://github.com/novifinancial/opaque-ke https://github.com/novifinancial/opaque-ke

8organicbits 5y ago

I wish there was a good way to implement this sort of double hashing in web apps. Doing the extra salted hash client side ensures that the value the server sees is globally unique, even when the user is reusing passwords across sites. Unfortunately the only way I know how to implement that is to have the server send JS down to the browser that instructs it to perform the hashing. For certain types of compromises server side, the attacker would just modify the JS to get the unhashed password. I'd also need to fall back to pure JS hashing for old browsers (5% users?), so there's a UX concern if I perform lots of rounds. I kind of wish there was a different password HTML field that could run the client side hashing without JS, so the browser would manage that. Ideally using different UX so the user understands they are using a "safe" password field. The end result would be to deny access to the raw password, which is likely reused on multiple sites.

faeyanpiraat 5y ago
But then malware on the user’s machine could catch that password. There is no 100% solution to this.
- 8organicbits 5y ago
  Different problems need different solutions. I don't think I've ever seen a solution that solves 100% of all problems. This doesn't stop me from trying to improve security where I see opportunity.
- lemarchr 5y ago
  Malware on the user's machine could catch the password in either case.
necovek 5y ago
Everything you explain points at no need to do client side hashing: what exact attack vector would be stopped by having it? (The only thing you bring up is reuse of passwords, but then you explain how that would be easily exploited if server was compromised, and it's even easier if client is) I would imagine most developers unfamiliar with encryption would assume that client hashing is sufficient and not bother with server side hashing which is the only one that ensures privacy in case of compromise on the server side (nothing really stops client side compromise).
- sixothree 5y ago
  I assumed the point would be to store all of the salt values ever used server side and never allow reuse of a salt. That way if the hash is captured but has already been used then it is useless.
kodah 5y ago
WASM will do what you want. You can certainly have client side JS produce a hash using some other credential as the salt and then encrypt the information server side. What you really lose is the ability to do low cost comparison, because most password hashing is done deterministically. Instead you would need to retrieve the record, decrypt with the server side key, and finally compare.

stingraycharles 5y ago

Which to me begs the question: then why hash client-side at all? What are the threats it protects against?

foobiekr 5y ago
Hashing client side has a non-cryptographic benefit of making all passwords a fixed length. This, in turn, helps avoid accidents with bcrypt misuse.
palant 5y ago
The client-side hashing is actually the part that keeps your master password a secret, from everyone including LastPass yourself. This makes sure that LastPass cannot decrypt your passwords despite them being stored there. The server-side part on the other hand is severely misimplemented and not much good to anyone. This is one of the issues I’ve written about here: https://palant.info/2018/07/09/is-your-lastpass-data-really-safe-in-the-encrypted-online-vault/ https://palant.info/2018/07/09/is-your-lastpass-data-really-...
SavantIdiot 5y ago
From what I understand: you still need the master password locally to decrypt the individual passwords. A hash won't provide that. All you're doing here is logging into LastPass.
chrisfosterelli 5y ago
This sort of scheme is common so that you do not have to share the encryption key with the provider. You derive two keys from your plaintext password: one used for authentication and one used for encrypting / decrypting the blob. This way, Lastpass can authenticate you without having to see the key to decrypt your data. Not sure the specifics of how lastpass implements this but this is a really common approach for end-to-end encrypted apps.
- necovek 5y ago
  I wouldn't say it's so you don't have to share the encryption key with your provider (you achieve that with a separate encryption key), but rather so you can use a single memorable secret for both login to the provider and local encryption. As in, the idea is that it is used to save you from having two secrets which might be more or less easy/hard to remember. It's a UX improvement (which might be a security imorovement on average too).