"8. Disclosure of Data
We may disclose personal information that we collect, or you provide:
...
Other cases. We may disclose your information also:
to our subsidiaries and affiliates; to contractors, service providers, and other third parties we use to support our business; for any other purpose disclosed by us when you provide the information;"
Who are these "subsidiaries" or "affiliate" companies? Data brokers?
From a company perspective it might be worth it to shave the 2-3 months to develop and perfect your own system. But from a user perspective, you are selling them out. Most people may not notice, but do you really want to risk the legal exposure or PR nightmare if their affiliate companies abuse this user data, or perhaps a subsidiary company leaves the data unencrypted in some db instance.
Why would anyone trust a third party with what is the most important asset, their users?
Thank you in advance.
As ever, there are trade offs and you take the good with the bad.
Best case scenario, there's healthy competition in the space, providing more alternatives and allowing you to end your contract with them if the service sucks. Worst case scenario I guess is that the company implodes taking all its data with it, affecting untold amounts of businesses. A GDPR-like regulation stipulating the ability to export that data (so, user databases) would go a long way towards mitigating prolonged outages in that worst case, and in the best case of the worst case, their competitors are able to import the exports. And/or tools that can spin up a $database instance in $cloud.
Also, if your issue is that owning your user passwords is difficult, then I'm sorry that's just the nature of the problem. It doesn't get any easier by offloading the problem to a third party. Bcrypting passwords is not rocket science anyway. MFA libraries exist for pretty much any server library you use.
Sure a company dedicated to doing user management will definitely do a better job than you, but only if your needs align with those of the majority of its users. The minute you want something custom,and trust me you will you're back to doing user management yourself. Only now you have a giant opaque blackbox to deal with.
Also, tomorrow if Google buys the company,I'll have 20 hours of notice to integrate my own user management before they shut it down. If Facebook buys it, they'll use my user data for targeting their advertising. Either way, I'm in deep trouble (If I care about my users, which I think most people will).
Even ignoring these, the simple fact is that by the very nature of the company, it is a much bigger target for people trying to break into and steal user information,than my little saas could ever be. I'd wager for most people using such services they'd be more likely to get hacked as collateral damage rather than being targeted.
If JaneService manages ten thousand credentials and has a breach, it could put JaneService out of business, but it won't affect MonicaSoft.
Now, trusting this particular third-party? Definitely a big question mark! It's on them to earn your trust. But I think to say that third parties in general can't be trusted with your users is to be a little ignorant of the modern web engineering landscape. We trust a lot of people with a lot of things, and not in an unreasonable manner.
I really can't think of any good reason to hand crucial control of a site over to any third party, much less user authentication where one breach will potentially cost you millions and land you in jail.
The whole business model seems to revolve around being a crutch for people not capable or competent of running their own services.
Because Auth0 and other providers have security experts specializing in prevent hacking attempts and there is no way you can do a better job than them unless you make it your full time job.
you don't have to use your real email for everything, even google has forwarding addresses.
and apple has private/forwarding emails as well, so this is a moot point.
I've even used G Mail's forwarding email for 6 years and I've never been hacked.
If you're concerned about this just use a fake email.
But you claimed that the email can be hacked, I used an email forwarding service provided by google or apple.
So are you saying I can be hacked through this way, please provide evidence of this happening in a real world passwordless scenario.
> An individual can mitigate them, but they still exist
Again, I would be more convinced of real world evidence and statistics rather than theorising.
I'm not arguing than an intelligent user can't get rid of security issues. I'm saying a product that uses passwordless login still has security issues. Not every user is going to do that and theyre gonna blame you when they get hacked.
> Again, I would be more convinced of real world evidence and statistics rather than theorising.
You first. You made the initial claim that passwordless login has no security issues. Systems should be assumed insecure unless proven otherwise.
Like what? you keep saying "still has security issues", but you don't give any real world examples. Just saying "still has security issues" is not a good argument.
> You first.
Lots of companies use this method in the real world, Slack, Medium, Freetrade, Substack, Monzo (a bank) and many more.
If a bank and a stock trading app is comfortable using this method, I am sure they are comfortable with the security of this method.
In addition, I already have given examples in this thread which you willingly choose to ignore.
Your turn, start with this:
> Forwarding email increases risk of being hacked. They only have to get one of the emails to get into my account.
Proof?
The point is that doing auth properly is hard. Sending an email might be easy, but creating and managing the session in a secure fashion is hard, even if you’re “just doing passwordless email auth”.
uh, yes?
> The point is that doing auth properly is hard...
it works just like password reset no?
there's not much state with passwordless email auth as opposed to passwords.
I don't think I understand exactly what your argument is.
> Sure, because “do passwordless emails” is just a snap of the finger away, right?
And I showed it literally is.
The choice is yours to reimplement this authentication system, but in terms of "a snap of the finger away", You can do that, That is all.
I've done these type of systems before at scale and it took minutes to do (works just like a password reset mechanism) and it is very trivial.
In your original comment above, I think you are projecting this a bit too much.
Next Comment: Because they are better at security
Your comment: Or you can do passwordless yourself and have no security problems
Next comment: You can't just do passwordless with a snap of the finger
Your comment: Yeah just use a 3rd party
You're incorrect about the thread
> The choice is yours to reimplement this authentication system, but in terms of "a snap of the finger away", You can do that, That is all.
It doesn't matter if it's a 3rd party, it is still an option that exists "a snap of the finger away", which was my response to that comment, this type of system can be done in an hour, 3rd party or library.
But if you want to speed things up, then there's your solution.
That was the point, but go ahead and try and reduce and spin this to your own interpretation.
First off, full disclosure: I don't work for Clerk; I work for a competitor which offers overlapping functionality, FusionAuth: https://fusionauth.io
I think a sibling comment laid it out well. It's a tradeoff. You are giving up some control over how your users are stored for significant acceleration of functionality. We've had customers say we saved them 1-2 person months of time in initial build, never mind ongoing maintenance.
Would you build an app using a database managed by someone else? Isn't data a crucial asset? Some call it the new oil, I've heard. Yet lots of people choose to use an outsourced database provider. Auth is more user facing than a database, but if you can get the data out, what's the difference?
That said, you should pick your own comfort level. Other options include self hosting (there are commercial and OSS solutions which you can run on your own hardware).
You should also have a frank conversation with any providers about their security posture (sounds like the Clerk folks are going to add some docs to their site about this, which is great.)
Another consideration: you want the ability to export your users should you want to move services. People who aren't self hosting with FusionAuth can get a database export from us, for example, if they want to migrate.
It's not even worth evaluating at the free tier without this. I asked in their slack and they said they intend to support this, which is promising (though sounds like it's not implemented yet)
There's also an argument to be made that companies like this could (certainly not guaranteed) employ security experts and have better implementations (through libraries) as a result. Those implementations could (if updated appropriately), yield a more secure auth solution. In that regard, going with a third party, who has expertise, could be "better".
Also, unless you're going to host your database that stores user data on prem, you're likely trusting a cloud with it.
If I missed the point of your question I'm sorry. Did my best to answer. I have no relation to any of these services, other than I've used some at times throughout my career.
Furthermore, with the economies of scale, there can be more investment done on security & protection of users by a common element. Think of it as a collection of companies pooling their resources on a single engineering team which is responsible for building a rock solid authentication system with many useful features. This helps little guys build on top of something which has the same efficacy as auth services that large companies can afford to build.
At the end of the day, it's a trade off.
A similar question that was asked only a few (10?) years ago, was "why would I trust a third party with my credit card data?" And now it's something that people don't think twice about, because of all the regulatory challenges around storing credit cards, and how bad a breach is.
We see auth, and more generically, basic user data, as a corollary to that. With User Data regulations popping up in different countries (GDPR/CCPA), in the next 5-10yrs, we think it will become pretty common place to use a service to offload some of these gnarly responsibilities.
The other concern is what happens if you shut down or decide to change your plan to be prohibitively expensive? (I'm not implying that's the case for you, but it's a consideration that has to be made). There have been vendors in the past that have abruptly shut down without warning, leaving their customers scrambling to build or find alternatives. In all honesty, I'd rather build an authentication system from the beginning than having to take my service down at a critical time.
This is actually a really interesting product though, and i would definitely consider it on future projects.
Auth0 maybe. Firebase is created by an advertising agency, so no.