6 ms·

Userbase dev here Yes, this is a thorny issue. We chose to offer a service that keeps user data end-to-end encrypted by default. With that choice comes this t

Userbase dev here Yes, this is a thorny issue. We chose to offer a service that keeps user data end-to-end encrypted by default. With that choice comes this tradeoff. And it’s a tradeoff similarly offered by practically every other end-to-end encrypted service I’m aware of. That being said, we have plans to alleviate the weight of this tradeoff, and we’ve already written nearly all of the code. That code is pending a security review and further refinement. The high level summary of it right now is: 1. you as the developer can opt to keep the user’s key stored in plaintext in local storage (via a single parameter passed to our signIn() method) 2. if a user forgets their password, they can get a temporary password emailed to them, then use it to sign back in 3. the user can then change their password normally

paublyrne 7y ago
If your product is SAAS aimed at helping to add authentication to simple apps with low lift, then I think it's a real problem. If I use this product in my product and my customer loses access to her account, then it becomes my problem, and my customer won't want to hear that I can't get their access back.
- j-berman 7y ago
  Agreed it would be a problem for a developer to use Userbase as is and not understand this is a tradeoff. I take it you think it's not clear this is a tradeoff, which is an issue, duly noted :) However, your customers also don't want to hear that you were hacked and all their sensitive data is now in someone else's hands. We offer easy-to-use protection from that increasingly common scenario. You (and your customers) also presumably don't want you to break privacy law regulations storing data. We offer a super simple service that helps you there.
  - oefrha 7y ago
    I think the problem is that there might not be too much overlap between projects so simple that developers would completely outsource user accounts and data management, and projects handling data so sensitive that it’s preferable to completely lose access when password is forgotten (which is very common) than tolerate the slim chance that data could be leaked through hacking.
    - j-berman 7y ago
      Perhaps, we'll see! My interest in this project was born out of wanting to do something similar for my own application. Didn't see any good options at the time and now there is one!
      - oefrha 7y ago
        Anyway, other than the password reset issue, this (the self-hosted version) is definitely something I have wanted at some point and might want again in the future. Good luck.
        j-berman 7y ago
        Thank you!
    - shanecleveland 7y ago
      Agreed. I can definitely see myself using this once password reset is an option. I am sure there are use cases with the existing functionality. Telling users their data will be irretrievable if they loose their password would certainly hurt conversions for many types of apps. And it would be a huge headache dealing with those who inevitably dismiss or fail to understand that.
  - geofft 7y ago
    > However, your customers also don't want to hear that you were hacked and all their sensitive data is now in someone else's hands. We offer easy-to-use protection from that increasingly common scenario. Generate an escrow keypair and ask the site owner to provide their own long passphrase for encrypting the private key. If a user needs to reset their password, they can contact the site developers who will need to key in the passphrase temporarily to generate a password reset link. Yes, this leaves various avenues of attack involving caches and whatnot to get to the private key while it's briefly decrypted, but it's still way more difficult than hacking a MySQL database, which is what you're trying to beat. (And it retains the property that I don't need to run a MySQL database.)
    - j-berman 7y ago
      This is tricky. If that single passphrase is mishandled, all of your user's data at rest is now vulnerable
- tzjmetron 7y ago
  Good point.
lovetocode 7y ago
Your response scares me. Are you sure you are in the right business?
- lovetocode 7y ago
  Seriously, why on earth would you even recommend storing a password in plaintext anywhere?
  - j-berman 7y ago
    I didn't down vote you, but in any case, that's not what I said. I should have been clearer, my bad. I said we'd store the user's key in local storage referring to the user's randomly generated key our client uses to encrypt data before sending to the server. Passwords are never stored in plaintext anywhere. We don't even send passwords to the server in plaintext -- we hash passwords client-side. But yes, even storing the key in plaintext in local storage has undesirable properties, which is why it's opt in. But an app that encrypts data with a key stored in local storage has a significantly higher level of privacy than an app that sends all data in plaintext to the server for storage.
    - giaour 7y ago
      > we hash passwords client-side Is that instead of or in addition to any hashing done on the server? It seems like doing all hashing on the client side essentially means that you would be storing plaintext passwords, since the value sent to you by the client would end up in a DB without modification. Curious as to why you went with client-side hashing as opposed to something like SRP.
      - j-berman 7y ago
        Short answer: because the password is used to encrypt the user's randomly generated seed, then the resulting ciphertext is stored on the server. If we didn't hash client-side and sent passwords in plaintext to the server, our end-to-end encryption scheme using password-based encryption would be broken (though I know that’s not exactly what you were saying) Long answer: Based off my understanding, we do implement something analogous to SRP with some minor differences. We'll have supporting documents explaining our approach complete with diagrams soon. But for right now, this is close to what the architecture looks like for clarity: https://user-images.githubusercontent.com/26468430/69532862-9077c480-0f2b-11ea-883a-b3ae0ebc7e30.png https://user-images.githubusercontent.com/26468430/69532862-... In order to be fully authenticated, the client must first prove they know the password token. The server then sends the client the password encrypted seed, then the client proves they can decrypt that seed (using Diffie-Hellman). So functionally the client is proving it knows both derivatives of the password to the server. Note there are 2 major differences between that image and what's currently in the code: 1. We also do a single SHA-256 hash of the password token before storing it on the server (prevents someone with access to only the server's data from passing round 1 of our authentication flow) 2. The optionals are not optional anymore, what I described above is how it’s working today. Disclaimer: there are a lot of missing pieces in the above description. So if it feels like there are gaps, that's why. It's difficult to explain the full scheme in a single comment like this. Our approach is pretty similar to Firefox's described here: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ https://hacks.mozilla.org/2018/11/firefox-sync-privacy/
mkl 7y ago
What if the reason they lost their password is their laptop died? Then the local storage is inaccessible, and the key is lost too.
- j-berman 7y ago
  Yep, it's a tradeoff. Similar to what if a user loses their Signal app's backup passphrase and their phone dies
ghego1 7y ago
Cool project! I am also not fully convinced by one choice though. If you're using the user password to decrypt the encryption key, why don't you simply derive the encryption key dinamically from the password each time the user logs in? I'm thinking of an algorithm that, given a string (the user's password), constructs a given key. Something like SHA-*, but more tailored to your use case. In this way you wouldn't need to store the encryption key anywhere, as it's dinamically generated on demand. As per the criticism on the user losing the password, I disagree with most comments. I think that if it's made very clear to the user why there is no recovery procedure, it can be a plus, but is has to be properly explained. Anyways, to solve this, I'll throw my 2 cents. The recovery process could be done woth a local-based (no server) Q&A process. For example, when the user creates the password it is asked to provide three security questions, and the corresponding answers. Then the questions are stored locally and the answers are used to create an encryption key to encrypt the password, which is then stored locally. If the user forgets the password, it is asked the three questions and if the answers are correct the password is correctly displayed. Now I know that many will tell me that storing the password in a database, even though encrypted, is a bad idea. But I'll respond that we are talking in this case of storing the encrypted password only locally. This means that to stole the password one would need phisical acces to the machine, and then it would need to crack the encryption. Which at this point makes this system much more secure than most SAAS that, while encrypting very well passwords server side, do allow (for obvious reasons) the user to stay logged in. So anyone with access to the machine can access all data without further work.
- ec109685 7y ago
  Why bother with password then and just ask security questions each time?
  - tobr 7y ago
    And why bother with any of this if it requires reliable persistent local storage anyway?
    - j-berman 7y ago
ec109685 7y ago
Instead of that, why don’t you just offer Sign In with Apple and Google’s equivalent. If you can reset a password via email, why bother storing anything in local storage. Let google and Apple be your IDP provider and use the identity they provide as that key?
- j-berman 7y ago
  In the approach I described, you wouldn't be able to reset a password via email alone. You would receive a temporary password via email when you trigger the forgot password mechanism. You'd then need to use the temporary password signing in from the browser that has the key still saved in local storage. You can't sign in with just the temporary password. You need the key as well. Using google or Apple like that would destroy the end-to-end encryption scheme
  - ec109685 7y ago
    I see. Two factor: something you have: local storage key; something you know: your email account password. Lose your device and use only password manager in device and you’d still be out of luck. That said, do you think the threat risk of trusting Apple with the encryption key for end to end encrypting data with Sign in By Apple is much different than the approach you are implementing? In both cases, at least you wouldn’t have access to the user’s data and you have to trust Apple to some extent given they are in charge of securing local storage and device security.
    - j-berman 7y ago
      If you use a password manager to save your password and don't lose access to the password manager, you are safe. All you need is your password to sign in. I was only describing the hypothetical approach we're planning to implement for someone who forgets their password. And yes, if I'm understanding right, I think those threat risks are very different. One is trusting your device which you yourself have control over, the other is trusting a cloud-based service provided by Apple, which you do not have control over. Not everyone uses Apple products either :) Edit: But alas, it's a user's choice how they want to save their password. If Apple provides a static key over this service and users really want this option, it's definitely worth exploring further :)
nbrempel 7y ago
You could also look into Shamirs’s Secret Sharing as a way to split up recovery keys. https://en.m.wikipedia.org/wiki/Shamir%27s_Secret_Sharing https://en.m.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
- j-berman 7y ago
  Yes this is a good option!
ThePowerOfFuet 7y ago
>keep the user's key stored in plaintext Nope.
- j-berman 7y ago
  We expect developers using Userbase are looking to take solid steps toward preventing personal data misuse. This option is still a vast improvement over the alternative of sending all data to a server in plaintext. And even still, you have the choice to do this or not and we make it clear in our documentation what your choice entails. You can keep everything in memory if you want https://news.ycombinator.com/item?id=22146764 https://news.ycombinator.com/item?id=22146764

paublyrne 7y ago

If your product is SAAS aimed at helping to add authentication to simple apps with low lift, then I think it's a real problem. If I use this product in my product and my customer loses access to her account, then it becomes my problem, and my customer won't want to hear that I can't get their access back.

j-berman 7y ago
Agreed it would be a problem for a developer to use Userbase as is and not understand this is a tradeoff. I take it you think it's not clear this is a tradeoff, which is an issue, duly noted :) However, your customers also don't want to hear that you were hacked and all their sensitive data is now in someone else's hands. We offer easy-to-use protection from that increasingly common scenario. You (and your customers) also presumably don't want you to break privacy law regulations storing data. We offer a super simple service that helps you there.
- oefrha 7y ago
  I think the problem is that there might not be too much overlap between projects so simple that developers would completely outsource user accounts and data management, and projects handling data so sensitive that it’s preferable to completely lose access when password is forgotten (which is very common) than tolerate the slim chance that data could be leaked through hacking.
  - j-berman 7y ago
    Perhaps, we'll see! My interest in this project was born out of wanting to do something similar for my own application. Didn't see any good options at the time and now there is one!
    - oefrha 7y ago
      Anyway, other than the password reset issue, this (the self-hosted version) is definitely something I have wanted at some point and might want again in the future. Good luck.
      - j-berman 7y ago
        Thank you!
  - shanecleveland 7y ago
    Agreed. I can definitely see myself using this once password reset is an option. I am sure there are use cases with the existing functionality. Telling users their data will be irretrievable if they loose their password would certainly hurt conversions for many types of apps. And it would be a huge headache dealing with those who inevitably dismiss or fail to understand that.
- geofft 7y ago
  > However, your customers also don't want to hear that you were hacked and all their sensitive data is now in someone else's hands. We offer easy-to-use protection from that increasingly common scenario. Generate an escrow keypair and ask the site owner to provide their own long passphrase for encrypting the private key. If a user needs to reset their password, they can contact the site developers who will need to key in the passphrase temporarily to generate a password reset link. Yes, this leaves various avenues of attack involving caches and whatnot to get to the private key while it's briefly decrypted, but it's still way more difficult than hacking a MySQL database, which is what you're trying to beat. (And it retains the property that I don't need to run a MySQL database.)
  - j-berman 7y ago
    This is tricky. If that single passphrase is mishandled, all of your user's data at rest is now vulnerable
tzjmetron 7y ago
Good point.

lovetocode 7y ago

Your response scares me. Are you sure you are in the right business?

lovetocode 7y ago
Seriously, why on earth would you even recommend storing a password in plaintext anywhere?
- j-berman 7y ago
  I didn't down vote you, but in any case, that's not what I said. I should have been clearer, my bad. I said we'd store the user's key in local storage referring to the user's randomly generated key our client uses to encrypt data before sending to the server. Passwords are never stored in plaintext anywhere. We don't even send passwords to the server in plaintext -- we hash passwords client-side. But yes, even storing the key in plaintext in local storage has undesirable properties, which is why it's opt in. But an app that encrypts data with a key stored in local storage has a significantly higher level of privacy than an app that sends all data in plaintext to the server for storage.
  - giaour 7y ago
    > we hash passwords client-side Is that instead of or in addition to any hashing done on the server? It seems like doing all hashing on the client side essentially means that you would be storing plaintext passwords, since the value sent to you by the client would end up in a DB without modification. Curious as to why you went with client-side hashing as opposed to something like SRP.
    - j-berman 7y ago
      Short answer: because the password is used to encrypt the user's randomly generated seed, then the resulting ciphertext is stored on the server. If we didn't hash client-side and sent passwords in plaintext to the server, our end-to-end encryption scheme using password-based encryption would be broken (though I know that’s not exactly what you were saying) Long answer: Based off my understanding, we do implement something analogous to SRP with some minor differences. We'll have supporting documents explaining our approach complete with diagrams soon. But for right now, this is close to what the architecture looks like for clarity: https://user-images.githubusercontent.com/26468430/69532862-9077c480-0f2b-11ea-883a-b3ae0ebc7e30.png https://user-images.githubusercontent.com/26468430/69532862-... In order to be fully authenticated, the client must first prove they know the password token. The server then sends the client the password encrypted seed, then the client proves they can decrypt that seed (using Diffie-Hellman). So functionally the client is proving it knows both derivatives of the password to the server. Note there are 2 major differences between that image and what's currently in the code: 1. We also do a single SHA-256 hash of the password token before storing it on the server (prevents someone with access to only the server's data from passing round 1 of our authentication flow) 2. The optionals are not optional anymore, what I described above is how it’s working today. Disclaimer: there are a lot of missing pieces in the above description. So if it feels like there are gaps, that's why. It's difficult to explain the full scheme in a single comment like this. Our approach is pretty similar to Firefox's described here: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ https://hacks.mozilla.org/2018/11/firefox-sync-privacy/

mkl 7y ago

What if the reason they lost their password is their laptop died? Then the local storage is inaccessible, and the key is lost too.

j-berman 7y ago
Yep, it's a tradeoff. Similar to what if a user loses their Signal app's backup passphrase and their phone dies

ghego1 7y ago

Cool project! I am also not fully convinced by one choice though. If you're using the user password to decrypt the encryption key, why don't you simply derive the encryption key dinamically from the password each time the user logs in? I'm thinking of an algorithm that, given a string (the user's password), constructs a given key. Something like SHA-*, but more tailored to your use case. In this way you wouldn't need to store the encryption key anywhere, as it's dinamically generated on demand. As per the criticism on the user losing the password, I disagree with most comments. I think that if it's made very clear to the user why there is no recovery procedure, it can be a plus, but is has to be properly explained. Anyways, to solve this, I'll throw my 2 cents. The recovery process could be done woth a local-based (no server) Q&A process. For example, when the user creates the password it is asked to provide three security questions, and the corresponding answers. Then the questions are stored locally and the answers are used to create an encryption key to encrypt the password, which is then stored locally. If the user forgets the password, it is asked the three questions and if the answers are correct the password is correctly displayed. Now I know that many will tell me that storing the password in a database, even though encrypted, is a bad idea. But I'll respond that we are talking in this case of storing the encrypted password only locally. This means that to stole the password one would need phisical acces to the machine, and then it would need to crack the encryption. Which at this point makes this system much more secure than most SAAS that, while encrypting very well passwords server side, do allow (for obvious reasons) the user to stay logged in. So anyone with access to the machine can access all data without further work.

ec109685 7y ago
Why bother with password then and just ask security questions each time?
- tobr 7y ago
  And why bother with any of this if it requires reliable persistent local storage anyway?
  - j-berman 7y ago

ec109685 7y ago

Instead of that, why don’t you just offer Sign In with Apple and Google’s equivalent. If you can reset a password via email, why bother storing anything in local storage. Let google and Apple be your IDP provider and use the identity they provide as that key?

j-berman 7y ago
In the approach I described, you wouldn't be able to reset a password via email alone. You would receive a temporary password via email when you trigger the forgot password mechanism. You'd then need to use the temporary password signing in from the browser that has the key still saved in local storage. You can't sign in with just the temporary password. You need the key as well. Using google or Apple like that would destroy the end-to-end encryption scheme
- ec109685 7y ago
  I see. Two factor: something you have: local storage key; something you know: your email account password. Lose your device and use only password manager in device and you’d still be out of luck. That said, do you think the threat risk of trusting Apple with the encryption key for end to end encrypting data with Sign in By Apple is much different than the approach you are implementing? In both cases, at least you wouldn’t have access to the user’s data and you have to trust Apple to some extent given they are in charge of securing local storage and device security.
  - j-berman 7y ago
    If you use a password manager to save your password and don't lose access to the password manager, you are safe. All you need is your password to sign in. I was only describing the hypothetical approach we're planning to implement for someone who forgets their password. And yes, if I'm understanding right, I think those threat risks are very different. One is trusting your device which you yourself have control over, the other is trusting a cloud-based service provided by Apple, which you do not have control over. Not everyone uses Apple products either :) Edit: But alas, it's a user's choice how they want to save their password. If Apple provides a static key over this service and users really want this option, it's definitely worth exploring further :)

nbrempel 7y ago

You could also look into Shamirs’s Secret Sharing as a way to split up recovery keys. https://en.m.wikipedia.org/wiki/Shamir%27s_Secret_Sharing https://en.m.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

j-berman 7y ago
Yes this is a good option!

ThePowerOfFuet 7y ago

>keep the user's key stored in plaintext Nope.

j-berman 7y ago
We expect developers using Userbase are looking to take solid steps toward preventing personal data misuse. This option is still a vast improvement over the alternative of sending all data to a server in plaintext. And even still, you have the choice to do this or not and we make it clear in our documentation what your choice entails. You can keep everything in memory if you want https://news.ycombinator.com/item?id=22146764 https://news.ycombinator.com/item?id=22146764