3 ms·

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,

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

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