
Show HN: Userbase – Add user accounts and persistence to your static site - DVassallo
https://userbase.com/
======
paublyrne
From the FAQ:

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

~~~
j-berman
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

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

~~~
withinboredom
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).

~~~
j-berman
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

------
soneca
Wow, that's _exactly_ what I needed.

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](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](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

~~~
j-berman
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!

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

0\. [https://github.com/encrypted-
dev/userbase/blob/master/src/us...](https://github.com/encrypted-
dev/userbase/blob/master/src/userbase-server/crypto/diffieHellman.js)

~~~
prophesi
Old isn't a valid critique with crypto; 2048-bit DH is verifiably secure.

~~~
tuxxy
Old is entirely a valid critique of crypto; it demonstrates the authors aren't
familiar with modern privacy tooling which tells me a lot.

~~~
j-berman
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.

[0]
[https://github.com/jedisct1/libsodium.js/#compatibility](https://github.com/jedisct1/libsodium.js/#compatibility)

------
tobr
Cool, I’ve been looking for something like this! Everything about it gives me
the right vibes.

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?

~~~
DVassallo
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).

------
naiyt
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/](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.

------
gbasin
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](https://twitter.com/dvassallo)

------
neiman
"The easiest way to get started is to create a free admin account..."

I'm surprised they don't use Userbase account for their own website.

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

[0]: [https://remotestorage.io/](https://remotestorage.io/)

------
adamlangsner
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?

~~~
DVassallo
Main differences:

\- An end-to-end encrypted database.

\- Super simple SDK.

\- 100% open source, MIT licensed. Both the backend and SDK.

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

EDIT :: Oh I just saw the Pro Plan plan in your tweet
[https://twitter.com/dvassallo/status/1216612542052589569](https://twitter.com/dvassallo/status/1216612542052589569)

~~~
DVassallo
Correct. Pro plan with unlimited metered storage, and support for collecting
payments coming soon. (Targeting end of April).

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

------
swyx
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")

------
stockkid
Congrats on shipping. The site looks slick and loads fast. What made you
choose the MIT license for your product over other licenses?

~~~
DVassallo
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).

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

~~~
DVassallo
Adding origin whitelisting is on the roadmap. We're working on 2FA to prevent
phishing.

And thank you!

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

Best regards, Heinrich

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

~~~
heinrichhartman
gotcha! Thx.

------
quickthrower2
I guess this is similar to Parse or Firebase?

~~~
DVassallo
It is. Main differences:

\- User data is end-to-end encrypted.

\- Super simple SDK.

\- Predictable pricing. (You won't need a cost calculator.)

\- 100% open source, MIT licensed.

~~~
tristador
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!

~~~
DVassallo
Thank you! — Addressed that in the FAQ:
[https://userbase.com/docs/faq/#faq-7](https://userbase.com/docs/faq/#faq-7)

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

