What happens if a user forgets the password?
Users should always keep a copy of their password in a safe place, such as a password manager. Since the encryption key needs to be decrypted by the user's password, it is not possible to recover an account if the password gets lost.
I don't believe this is acceptable for a user authentication service. Password reset functionality must be present for this to be production ready.
End-to-end encryption is one of the main features of the product. Since the key is user-controlled, there will always be something that the user must keep and never lose. For this first version, we chose to make that thing the user’s own password.
Other end-to-end encrypted apps (such as password managers) have the same requirement. Sometimes the password is resettable, but you have to keep another key. But there’s always something that would lock you out if you lose it.
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
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.
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 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.
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.
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!
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.
> 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.)
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.
Why have a password at all? Just use webauthn if a device is available and skip the password completely (or give the user/dev a choice -- password sharing may make sense in a lot of contexts).
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 that, but will definitely be looking further into webauth to explore this possibility some more, thanks for the tip
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 :)
the proper way for them to implement this would have been PAKE since they are customer facing for domains that may or may not even have a need for e2ee.
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 future to explain it some more. Will explain it in more detail here (but be warned, it's still missing some steps and may seem a little convoluted to follow):
--Sign up--
1. user signs up and client generates a random seed in memory
2. client takes user's seed and inputs it through HKDF to derive a Diffie-Hellman key pair
3. client inputs user's password once through Scrypt, and then twice through HKDF to derive 2 values: password token & password-based encryption key
4. client encrypts user's seed from step 1 using password-based encryption key from step 3
5. client sends server the user's public DH key, password-encrypted seed, and password token for storage
--Sign in--
1. user inputs username and password
2. client inputs password once through Scrypt, and then twice through HKDF to derive 2 keys: password token & password-based encryption key
3. client sends server password token
4. server verifies password token matches stored token, and sends client a random message encrypted to the client's public DH key that was stored at sign up, along with the password-encrypted seed
5. client decrypts password-encrypted seed using password-based encryption key from step 2
6. client takes user's seed and inputs it through HKDF to derive DH key pair
7. client uses private DH key to decrypt random message from step 4 and sends plaintext message to server
8. client is now authenticated
Overall this approach is somewhat similar to Firefox's approach with Firefox Sync [1]
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?
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
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.
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 :)
Good point. I think what ultimately should be done is browsers should provide access to secure tokens that are stored in the user’s keychain (or Google equivalent).
The Keychain is end to end encrypted and they have done the hard work in propagating data securely across devices. Then there are no passwords and user is in control over which devices have access to their data. Access to device equals access to data, which I think most people would be comfortable with (e.g. you don’t sign into your email account on your phone each day).
> Why are you typing like this. There is no reason for why you are doing this, so why are you doing it.
> The only sentence that wasn't actually a question had the only question mark?
Sorry for insulting your writing style, but this is very confusing to me on many levels, and while I've seen it elsewhere, I've never been able to ask someone why. Why are you doing this? This, of course, being "using punctuation marks in the opposite way that they're intended to be used."
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
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.
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.
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:
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.
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 :)
That'll absolutely not happen in our lifetime if ever. You're projecting your developer centric view onto non-technical users who demand solutions that don't add friction to their lives, if it does it's not solving a problem but just adding a new layer of problems for them.
So not true. Browser and OS vendors recognize this problem. “Store this key securely and provide it to me” makes sense to implement, so websites can take advantage of all the hardening and security features of the device versus hoping someone doesn’t share a password between two sites.
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 :)
Gosh, I would love if more services didn't offer any account recovery, and refused email/password combos found in HaveIBeenPwned. With perhaps a discount code for a password manager below the sign-up form.
I see a lot of comments challenging the founder's choice on the trade-off "e2e encryption vs users losing their passwords", so I will explain my use case.
I am building a social network (https://www.quidsentio.com) with the idea of creating one that reduces the noisiness of current ones (that's why I am calling it a "quiet social network") and also is more privacy-oriented.
I see privacy as freedom from being observed, and I am considering three dimensions: free from being observed by strangers (you only add real friends to your network), free from being observed by companies (no ads, no tracking), and free from being observed by thieves (prepared for data breaches).
That last point is the harder technical problem to solve and Userbase seems to solve it well. As privacy is a big part of what I am building, I consider the trade-off acceptable for my product. Of course, my copy and UX will have to be especially good to not frustrate users on that end.
Still, it is a hard decision to make for a product. But the recovery after lost password option that one of the founders mentioned in one of the comments below (https://news.ycombinator.com/item?id=22145878) was decisive, so now I am pretty sure I will add e2e to my product.
Other features that make it perfect for me:
- It's a SaaS, which helps a lot a solo founder not having to build and maintain an authentication service
- It's an API, fits well my serverless architecture (I am using Netlify hosting, Netlify Functions, and FaunaDB)
- It's cheap (I am using now Netlify Identity, which is $99/month per 5,000 users after the free tier of 1,000)
So, thanks for your work, I will for sure be a happy customer, and I am more excited to make this bet that privacy is/will be something that matters for all people, not just worried developers
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!!
I took a cursory look at the crypto on the backend, and it was mildly concerning. It appears to not be using modern asymmetric primitives. At first glance, it's not insecure or anything... just old[0].
Rather than using something like libsodium's public-key box API, which is wonderful, it's using a 2048-bit Diffie-Hellman Prime group. This isn't really great. You should definitely upgrade to more modern primitives. I can highly suggest libsodium as a drop-in replacement.
The other thing about this that's more concerning is that I have no idea if there is any validation going on to prevent small subgroup confinement attacks on this, but I don't really want to spend anymore free time checking this out and I'll leave it as an exercise for the reader/author.
Personally, I wouldn't use this product until a few cryptography design decisions were changed. If you're marketing this as a privacy-centric product, there's a lot of work to be done--not just on the Diffie-Hellman usage.
We looked at libsodium and its choices impacted our discussions on our system. We decided not to use it because it's not compatible with many browsers [0]
We also discussed using a modern asymmetric key algorithm. We decided on Diffie-Hellman because we were extremely confident it's secure (so long as we choose the right parameters and implement it correctly), and would be very simple to fit it into our architecture.
We’re marketing this as something that can significantly reduce personal data misuse compared to having user data sitting in clear in a MySQL database. The value-add is mainly to the developers. (Although the devs can choose to promote some of that to their users too.)
Thank you. Working on it. The next version is expected to have a feature to allow you to export all the data to your own self-hosted backend (without any downtime).
Wow, this is fortuitous for me. I've been wanting something like this for quite some time, and was literally just thinking about it this morning. I've had a lot of ideas for certain small side projects that have ended up dead in the water, because I really didn't want to even risk being liable for the type of user data I would be storing.
This solution is perfect for an application that's targeting privacy focused users. I often don't sign up for services these days because I don't care for the possibility that the maintainer of the site is just casually reading through my data.
Some great use cases could be journaling, note taking, a private wiki, etc. For note taking, I actually use Standard Notes (https://standardnotes.org/) precisely because of its end to end encryption.
For me the lack of password reset is a non issue (especially with modern password managers), something that I gladly trade for the peace of mind that some random developer with database access isn't reading through my private stuff. Obviously if you built something on top of this, you would need to properly educate your users on the tradeoff they're taking.
Daniel has been tweeting his journey from Amazon employee to solo-preneur. It's been very fun to follow, I would recommend: https://twitter.com/dvassallo
There's a protocol for this and it's called remoteStorage[0]. It has a JavaScript implementation that just works and different compatible servers, plus anyone can run its own.
What are the differences between this product and Auth0? Why would a dev choose one over the other? Do they target different developers / stacks. Or are they both vying for the same thing?
The title is advertised as for static site, but If I wanted to build my "app" on top of Userbase, I'd love to pay for extra storage. (Keep the simple pricing, just add a separate storage plan)
I really like the model of open source SASS, I hope users will still pay as I plan my own open source SASS for video edition. I think it is the best compromise between my open source values and the basic requirement to make money in life.
where do social logins like github and twitter rank in your list of priorities?
on a more meta level, since you're so open anyway, might want to look into public feature voting/roadmaps.
congrats on launching! you know i'm a fan of your work. I don't have a particular use for this product as is right now but gh and twitter logins would actually change my calculus (haha i know this is the annoying user stereotype of "i wont use this unless i have x")
Wanted it to be open, no strings attached. The business comes from providing high-quality hosting and (eventually) pro services (support for accepting payments, etc).
congratulations on the launch!
are there any checks done on the backend to guarantee that the website using the "init(appId)" call is the right one?
The attack vector here is a fake website - say "userbose dot com" - where the login would be validated by the backend and can now access all data for that user.
Congrats! This looks like a really nice service. Thanks for making this!
I am not a front-end preson, but I run a static Jekyll blog hosted on GitHub.
I don't want to miss the zero maintenance (!) ease of deployment and network-performance of the GitHub CDN, but I have been missing some dynamic features. Most notably:
1. A view counter per page
2. Comments
3. Signup for Newsletter Form
Since the GDPR landed, I have removed my Google Analytics and Disqus plugins. And I am happy with that. No reason to leak PII to third parties, that I can't trust anymore.
Is that a use case you want to be supporting on your platform?
Looks like, this should not be hard to build with your SDK.
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
Are you thinking of user-to-user sharing (ex: daniel shares his list with justin) or something more global?
To give an example:
The indiehackers website uses firebase as its data store. It's a blog/forum, so posts and comments made by individual users can be seen by people who don't have accounts. Is this a use case you plan to support in the future?
If not, the potential use cases are much narrower than firebase. Not necessarily a bad thing but I'm just trying to understand the product.
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 Userbase if you want to store lots of data that anyone would be able to see
Adding on to this, Firebase isn't structured to support end-to-end encryption by default. Our client-server architecture is built and optimized for that intention. I don't think you could build a performant end-to-end encrypted application with Firebase very easily. Userbase fills that role with a super simple SDK
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) :)
FWIW the current pricing page shows only a starter plan that caps you to 1GB, with no info about what happens after 1GB. Predictable pricing is a good feature, but you don't have that yet.
Really cool otherwise, I may use this for something. Great work!
We’re not metering storage yet, so nothing will happen right now. Soon we’ll have another pricing plan with metered storage, and people who happen to be exceeding the limit will be given the choice to upgrade to unlimited metered storage (ala AWS).
What happens if a user forgets the password? Users should always keep a copy of their password in a safe place, such as a password manager. Since the encryption key needs to be decrypted by the user's password, it is not possible to recover an account if the password gets lost.
I don't believe this is acceptable for a user authentication service. Password reset functionality must be present for this to be production ready.
Other end-to-end encrypted apps (such as password managers) have the same requirement. Sometimes the password is resettable, but you have to keep another key. But there’s always something that would lock you out if you lose it.
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
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 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.
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!
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.)
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.
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!
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 :)
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 future to explain it some more. Will explain it in more detail here (but be warned, it's still missing some steps and may seem a little convoluted to follow):
--Sign up--
1. user signs up and client generates a random seed in memory
2. client takes user's seed and inputs it through HKDF to derive a Diffie-Hellman key pair
3. client inputs user's password once through Scrypt, and then twice through HKDF to derive 2 values: password token & password-based encryption key
4. client encrypts user's seed from step 1 using password-based encryption key from step 3
5. client sends server the user's public DH key, password-encrypted seed, and password token for storage
--Sign in--
1. user inputs username and password
2. client inputs password once through Scrypt, and then twice through HKDF to derive 2 keys: password token & password-based encryption key
3. client sends server password token
4. server verifies password token matches stored token, and sends client a random message encrypted to the client's public DH key that was stored at sign up, along with the password-encrypted seed
5. client decrypts password-encrypted seed using password-based encryption key from step 2
6. client takes user's seed and inputs it through HKDF to derive DH key pair
7. client uses private DH key to decrypt random message from step 4 and sends plaintext message to server
8. client is now authenticated
Overall this approach is somewhat similar to Firefox's approach with Firefox Sync [1]
[0] https://news.ycombinator.com/item?id=22146651
[1] https://hacks.mozilla.org/2018/11/firefox-sync-privacy/
https://en.m.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
Let google and Apple be your IDP provider and use the identity they provide as that key?
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
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.
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 :)
The Keychain is end to end encrypted and they have done the hard work in propagating data securely across devices. Then there are no passwords and user is in control over which devices have access to their data. Access to device equals access to data, which I think most people would be comfortable with (e.g. you don’t sign into your email account on your phone each day).
> The only sentence that wasn't actually a question had the only question mark?
Sorry for insulting your writing style, but this is very confusing to me on many levels, and while I've seen it elsewhere, I've never been able to ask someone why. Why are you doing this? This, of course, being "using punctuation marks in the opposite way that they're intended to be used."
Nope.
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
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.
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.
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/
Appreciate the apology :)
The final user may even think wanting something like this. Until they ultimately lose their password.
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 :)
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 see a lot of comments challenging the founder's choice on the trade-off "e2e encryption vs users losing their passwords", so I will explain my use case.
I am building a social network (https://www.quidsentio.com) with the idea of creating one that reduces the noisiness of current ones (that's why I am calling it a "quiet social network") and also is more privacy-oriented.
I see privacy as freedom from being observed, and I am considering three dimensions: free from being observed by strangers (you only add real friends to your network), free from being observed by companies (no ads, no tracking), and free from being observed by thieves (prepared for data breaches).
That last point is the harder technical problem to solve and Userbase seems to solve it well. As privacy is a big part of what I am building, I consider the trade-off acceptable for my product. Of course, my copy and UX will have to be especially good to not frustrate users on that end.
Still, it is a hard decision to make for a product. But the recovery after lost password option that one of the founders mentioned in one of the comments below (https://news.ycombinator.com/item?id=22145878) was decisive, so now I am pretty sure I will add e2e to my product.
Other features that make it perfect for me:
- It's a SaaS, which helps a lot a solo founder not having to build and maintain an authentication service
- It's an API, fits well my serverless architecture (I am using Netlify hosting, Netlify Functions, and FaunaDB)
- It's cheap (I am using now Netlify Identity, which is $99/month per 5,000 users after the free tier of 1,000)
So, thanks for your work, I will for sure be a happy customer, and I am more excited to make this bet that privacy is/will be something that matters for all people, not just worried developers
Thank you!
Rather than using something like libsodium's public-key box API, which is wonderful, it's using a 2048-bit Diffie-Hellman Prime group. This isn't really great. You should definitely upgrade to more modern primitives. I can highly suggest libsodium as a drop-in replacement.
The other thing about this that's more concerning is that I have no idea if there is any validation going on to prevent small subgroup confinement attacks on this, but I don't really want to spend anymore free time checking this out and I'll leave it as an exercise for the reader/author.
Personally, I wouldn't use this product until a few cryptography design decisions were changed. If you're marketing this as a privacy-centric product, there's a lot of work to be done--not just on the Diffie-Hellman usage.
0. https://github.com/encrypted-dev/userbase/blob/master/src/us...
We also discussed using a modern asymmetric key algorithm. We decided on Diffie-Hellman because we were extremely confident it's secure (so long as we choose the right parameters and implement it correctly), and would be very simple to fit it into our architecture.
[0] https://github.com/jedisct1/libsodium.js/#compatibility
seems like it'll break on firefox now.
https://github.com/crypto-browserify/diffie-hellman/blob/mas...
If I build a prototype on this, and get some users - is there a path to migrate their accounts and data to a new backend in the future?
This solution is perfect for an application that's targeting privacy focused users. I often don't sign up for services these days because I don't care for the possibility that the maintainer of the site is just casually reading through my data.
Some great use cases could be journaling, note taking, a private wiki, etc. For note taking, I actually use Standard Notes (https://standardnotes.org/) precisely because of its end to end encryption.
For me the lack of password reset is a non issue (especially with modern password managers), something that I gladly trade for the peace of mind that some random developer with database access isn't reading through my private stuff. Obviously if you built something on top of this, you would need to properly educate your users on the tradeoff they're taking.
I'm surprised they don't use Userbase account for their own website.
[0]: https://remotestorage.io/
- An end-to-end encrypted database.
- Super simple SDK.
- 100% open source, MIT licensed. Both the backend and SDK.
EDIT :: Oh I just saw the Pro Plan plan in your tweet https://twitter.com/dvassallo/status/1216612542052589569
on a more meta level, since you're so open anyway, might want to look into public feature voting/roadmaps.
congrats on launching! you know i'm a fan of your work. I don't have a particular use for this product as is right now but gh and twitter logins would actually change my calculus (haha i know this is the annoying user stereotype of "i wont use this unless i have x")
And thank you!
I am not a front-end preson, but I run a static Jekyll blog hosted on GitHub. I don't want to miss the zero maintenance (!) ease of deployment and network-performance of the GitHub CDN, but I have been missing some dynamic features. Most notably:
1. A view counter per page
2. Comments
3. Signup for Newsletter Form
Since the GDPR landed, I have removed my Google Analytics and Disqus plugins. And I am happy with that. No reason to leak PII to third parties, that I can't trust anymore.
Is that a use case you want to be supporting on your platform? Looks like, this should not be hard to build with your SDK.
Best regards, Heinrich
If you have a todo app, the user can log in and see and modify their todos but there would be no way for them to share their todos.
There is no shared access to a modifiable store which I believe would be necessary for the view counter, comment, and signup use cases.
To give an example: The indiehackers website uses firebase as its data store. It's a blog/forum, so posts and comments made by individual users can be seen by people who don't have accounts. Is this a use case you plan to support in the future?
If not, the potential use cases are much narrower than firebase. Not necessarily a bad thing but I'm just trying to understand the product.
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 Userbase if you want to store lots of data that anyone would be able to see
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) :)
- User data is end-to-end encrypted.
- Super simple SDK.
- Predictable pricing. (You won't need a cost calculator.)
- 100% open source, MIT licensed.
Really cool otherwise, I may use this for something. Great work!
We’re not metering storage yet, so nothing will happen right now. Soon we’ll have another pricing plan with metered storage, and people who happen to be exceeding the limit will be given the choice to upgrade to unlimited metered storage (ala AWS).