j-berman

8 ms·

31.
by j-berman 7y ago
So long as we're able to get a strong static secret value from users, password or otherwise, that's all that matters. When we first looked into alternative auth mechanisms, it appeared that they did not provide us a value like tha
32.
by j-berman 7y ago
We expect all of our customers to have a need for e2ee. And we do implement a PAKE. For reference, I explained our approach a bit in this comment [0], and mentioned how we'll have more documents and diagrams available in the near futur
33.
by j-berman 7y ago
I thought that old + verifiably secure combine for the safest property in a crypto algorithm
34.
by j-berman 7y ago
User-to-user sharing (because data created using Userbase is private) Edit: technically you could do something hacky like share the database with a user who broadcasts the data somewhere. But I don't think you'd want to use Userba
35.
by j-berman 7y ago
This is an awesome comment and makes me very happy. Though I'm not a founder, just the first employee :) Looking forward to seeing what you create with it!! Thank you!
36.
by j-berman 7y ago
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 use
37.
by j-berman 7y ago
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
38.
by j-berman 7y ago
We don't use WebCrypto for DH, we're using this npm package: https://github.com/crypto-browserify/diffie-hellman/blob/mas...
39.
by j-berman 7y ago
Yes! This would be awesome
40.
by 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
41.
by 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
42.
by j-berman 7y ago
Yes this is a good option!
43.
by 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
44.
by j-berman 7y ago
Thank you!
45.
by j-berman 7y ago
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 dia
46.
by j-berman 7y ago
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 memor
47.
by 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!
48.
by 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-
49.
by j-berman 7y ago
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
50.
by 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
51.
by 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 w
52.
by j-berman 7y ago
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 mo
53.
by j-berman 7y ago
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 pr
54.
by j-berman 7y ago
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-e