j-berman

If I'm understanding correctly, just like u/guu said, each of these features would require sharing data between users of your app. We're currently working on getting data sharing shipped! But for right now, it can only be used for a single user to store their own data.

This is correct for right now, but data sharing is a feature we're currently in the process of wrapping up and getting reviewed by an independent security team. So this will be possible in the near future

We don't use WebCrypto for DH, we're using this npm package:

https://github.com/crypto-browserify/diffie-hellman/blob/mas...

Yes! This would be awesome

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 :)

Yep, it's a tradeoff. Similar to what if a user loses their Signal app's backup passphrase and their phone dies

Yes this is a good option!

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

Thank you!

This is not the case, right now all a user needs to sign in is their password.

Only that particular password reset mechanism I described benefits from local storage. It's difficult to explain in one comment. We'll have clearer diagrams and explanations soon :)

Agreed! We actually have 3 options available for developers to choose from right now: local storage, session storage, or memory.

The memory option does exactly what you said, derives the encryption key dynamically from the password in memory.

It's actually a bit more complex in how it works under the hood (i.e. the above isn't exactly how it works), happy to get deeper into the details :)

Note this option is provided in the form of the rememberMe parameter here: https://userbase.com/docs/sdk/sign-in/

Your Q&A scheme is also definitely a plausible backup option! Thanks for the suggestion!

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!

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-...

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/

Protecting data is solving a problem almost everyone is interested in, including non-technical people.

And the existence of password managers disproves your claim regardless. It adds more friction to my life to use a password manager versus an insecure password.

We're hitting a very particular tradeoff with this product, one which is largely untapped. We'll see which way the chips fall :)

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.

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.

I personally think (and hope) the ever-growing issues surrounding data privacy and the constant stream of data breaches we hear about will push people to demand solutions like this and embrace the tradeoff that comes with it. Hope we get more people using password managers. Hope we get more people thinking more deeply about how they can protect their data.

Time will tell what the people want! :)

That's my idealistic way of looking at it. Practically speaking, the burden on developers to adhere to GDPR and other data privacy laws is quite high. You can use this service to store sensitive user data and relax :)

Userbase dev here -- yep, biggest difference from both being that user data is end-to-end encrypted with the user's password by default.

Compared to Parse, we offer a simple SaaS product.

Compared to Firebase, we have a much simpler pricing structure.

Considering how early on we are, we also have the benefit of being much simpler to start using (fewer features/options to wrap your head around and configure) :)

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