10 ms·

Never outsource Auth. Maintain control over user accounts. That's the life blood of your business. If you have to ask everyone to reset their password because y

Never outsource Auth. Maintain control over user accounts. That's the life blood of your business. If you have to ask everyone to reset their password because your auth provider increases their pricing or goes out of business, the churn will likely kill your company. I would say the same for Stripe, but at least they'll help you migrate off their platform. Auth providers cant help you because the passwords are hashed... You need the same algo or you cant authenticate using the data they have. And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period. Pick an auth provider and you better believe in their business as much as your own. You will incur damage when you leave.

ocdtrekkie 5y ago
It is probably true that outsourcing your authentication to another party is probably bad, you probably should not write your own. So you should likely use a package for your auth code written by someone who focuses heavily on that.
- AlchemistCamp 5y ago
  In Elixir-land we're lucky. Jose Valim took his experience from writing Devise (the dominant Ruby gem for auth) and made auth generators for Phoenix apps! You own the user table, but the auth logic is written by an expert.
void_mint 5y ago
> Never outsource Auth. Maintain control over user accounts. This is some of the worst advice I've ever seen on HN. Don't take on risk you don't understand and cannot afford to mitigate. Don't be the next Equifax.
- troygoode 5y ago
  100%. I'm old enough that when I started my career we were still storing credit card numbers on our servers (and many companies were unfortunately doing so in the raw...). PCI compliance luckily knocked some sense into the industry. Crazy to me that some people don't realize that PII and secrets like passwords are basically in the same category now.
- Raed667 5y ago
  It is really not difficult to use BCrypt or Argon2 with your backend of choice. Proper password and session management have been made accessible for many years if you use any "modern" backend.
  - void_mint 5y ago
    > Its really not difficult Good luck to you!
  - city41 5y ago
    It's true the happy path and common error cases are easy to account for. But it just takes one overlooked bug or vulnerability either in your code or a library's code to send it all crashing down.
    - arcbyte 5y ago
      This is true across the board. One tiny crack in a bridge might mean it will collapse. That doesn't mean we should stop building bridges.
      - void_mint 5y ago
        Sure, but it certainly means we should leave bridge building to those who are experts in that field.
  - bhaney 5y ago
    > It is really not difficult to use BCrypt Something I once saw in production: An otherwise normal usage of bcrypt, that "prehashed" the password with sha512 before passing the resulting hash to bcrypt. This is conceptually reasonable (although not very useful) for reasons I don't think are worth going into, but had two critical problems. 1. It technically broke bcrypt's side-channel protection against timing attacks (bcrypt runs in constant time, while sha512 does not). 2. The much worse issue was that the binary hash was being passed to bcrypt. If bcrypt encounters a null byte in the input, it considers that to be the end of the input and ignores everything after, c-string style. Every byte of the binary hash had a 1/256 chance of being a null byte, which means 1/256 passwords result in a hash with the first byte being null, which means bcrypt will accept any of them as equivalent to the others. You could login to 0.4% of accounts by guessing ~256 completely random passwords (and a larger number of passwords were similarly but less extremely weakened) You can say "well that's their fault for mucking with the input to bcrypt" but I bet most people would believe that kind of operation was safe before it's explained to them why it's not. It's very easy to accidentally destroy the security of a crypto scheme without knowing it, and thinking that what you're doing is perfectly run of the mill and safe.
- dvdkon 5y ago
  In what scenario do you need to have personal info associated with accounts and don't need to have full access to it? I see no user privacy benefits to outsourcing auth, unless all you need is to do is to verify someone's a real person.
- guiomie 5y ago
  But he's arguments are pretty sound to me. Do you have any counter-arguments than a generic statement?
  - jayd16 5y ago
    I guess the question is what's more likely, Facebook, Google or Apple leaving the oauth game or a bug in an internal solution.
    - bryanrasmussen 5y ago
      what's more likely - you being able to talk to Facebook, Google, or Apple to let your app/site use their authorization solution once their algorithm has decided to ban you, or you fixing your bug.
    - capableweb 5y ago
      You're missing the original point. rgbrenner is talking about auth solutions like Auth0 where users can use username + password to sign up/login, and when you eventually are gonna have to leave (which, if your business is successful, you eventually will), you'll need to reset passwords one way or another. Of course, if you only use third-party authentication for your service, it doesn't really matter what's in-between there, you can work around it.
    - habibur 5y ago
      That they will ban you for one reason or other has a very high possibility of occurring before you go out of business.
      - jayd16 5y ago
        You and I have different definitions of very high possibility.
        withinboredom 5y ago
        I had an app get banned for copyrighted content by Google because there was a movie poster in one of the backgrounds of the screenshots (camera type app in 2013). It will happen, probably for something ridiculous. In every job I’ve worked at, it had happened or they’d been threatened to be banned, at least once.
- remram 5y ago
  I don't think the main problem with Equifax was the Auth info they lost. It was their own business data, e.g. social security numbers etc, which wouldn't have been outsourced to their Auth provider anyway.
- debaserab2 5y ago
  This is literally the Auth0 first contact sales pitch designed precisely to scare you out of even trying to assess the risk of building it yourself. The reality is, though, it's never been easier than it is today to build secure auth - yes, it's still hard to do it right - but less hard than it ever has been before. So many security features are now a checkbox on a cloud provider's web interface that would have been a manual implementation of the underlying protocol a decade ago. So many languages have matured battle-tested OS libraries for handling the especially sensitive parts like crypto. This notion that it is a "no-brainer" decision to happily trade your customer database and a % of revenue to remove the burden of stewardship seems crazy to me.
  - deergomoo 5y ago
    Not to mention there’s a whole lot of middle ground between writing your own auth logic and using a hosted service. Any reasonably popular web-oriented language has plenty of fully featured, high quality libraries you can often just drop in. Hell, we use Laravel at work, which includes pretty robust auth features out of the box. It feels like such table stakes stuff for a web framework that I find the idea of paying for a third-party cloud service absolutely bananas. It also includes pretty solid notification and payment solutions too, though these usually plug into services like SNS and Stripe and don’t really fit the “self hosted” bill.
    - beardbandit 5y ago
      I think that's where the confusion lies. Are people suggesting someone to write their own auth from the ground up, or write auth in coordination with their stack's auth library of choice?
      - joshmanders 5y ago
        It appears to me the assumption these people / articles make is that nobody is using existing hardened production ready libraries, but hand writing everything from the ground up for their todo app. Because otherwise their message falls flat on its face.
- justinclift 5y ago
  Well, we implemented Auth using Auth0. The experience wasn't terrible, but not fantastic either. Probably best described as "ok". However, now they've been bought by Okta, which has a pretty bad reputation. So, I guess we'll get to find out eh?
AlexSW 5y ago
Using the same authentication algorithm doesn't seem like a particularly big price to pay, assuming they started with a sensible one. And there's nothing stopping one from making it support the old style but add a more up-to-date algorithm for new password sets, either.
deleted 5y ago
[deleted]
chaostheory 5y ago
You can do both. Just use an open source project for auth instead of reinventing a commodity wheel.
mooreds 5y ago
You can also choose to self host. Keycloak and FusionAuth (disclosure, I am an employee) let you self host. You then have the user database in your systems. > And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period. Actually, not true. I can't speak for every auth provider, but FusionAuth and Auth0 both let you have the password hashes. If you know the algo (ask your provider!), you can load the hashes (and other ancillary password data like the salt) and your users will never be the wiser. Here's a guide I wrote about how to migrate off of Auth0: https://fusionauth.io/docs/v1/tech/guides/auth0-migration/ https://fusionauth.io/docs/v1/tech/guides/auth0-migration/ The end goal of the guide is to move to FusionAuth, but the steps to get your password hashes out of Auth0 (the 'Exporting Users' section) will work no matter where you migrate to.
- rvense 5y ago
  I'm currently implementing Keycloak for my startup. It's not perfectly documented, but I really like all the things it can do for us and how extensible it is.
  - mooreds 5y ago
    I'd suggest checking out FusionAuth, but I'm a bit biased :) . I have heard good and bad things about Keycloak, but I know one thing for sure: it's far better than rolling your own auth. Good luck with your startup!
    - outime 5y ago
      I understand that you want to promote your solution and you have a disclaimer in the previous comment - and that's great. But if you keep insisting then you should IMHO at least provide some reasons on why your solution may be better than e.g. Keycloak and not just posting the name a couple times and see if it sticks.
      - 5y ago
remram 5y ago
Making people reset their password is not that big of a deal. I have run into this multiple times, the most recent being amtrak.com. It just told me "you have to reset your password" and I got a link in email like if I had forgotten it. I have also received many "we had a security incident you have to reset your password now" emails in recent years.
- sam_lowry_ 5y ago
  There is a whole line of thought that accounts should be passwordless and accessed via an email reset link as part of normal login procedure.
  - slavboj 5y ago
    Which is great until you lose access to your email.
    - em-bee 5y ago
      if you loose access to your email, you may just be out of luck. a good service will not allow you to change your registered email address without verifying that you own the old one
      - yawaramin 5y ago
        Not in my experience. Every account I can think of allows me to change my email address without verifying the old one.
    - dstick 5y ago
      And how would you even login to your email using that method :)
  - jedberg 5y ago
    Yeah I hate that method. It's good in theory but terrible for the user. I go to a website I want to use. I click the magic link. The email takes 10 seconds to show up. In that 10 seconds I find something else to do while I'm waiting. I get distracted and find the magic link in my email 10 minutes later. It's now expired and I have to start over. Or just give up. With a password, I click the site I want to use, my password manager fills in the password for me, and I click "login" and bam, I'm done.
unethical_ban 5y ago
It's one thing to host your own/maintain your own auth database, but there is a definite benefit of using a tool like Okta SSO to link your authn to other services, if that's your business.
patwolf 5y ago
I've built auth systems from scratch and used third party auth services. Doing it from scratch always feels reasonable at first when it's just basic username and password, But I start to regret it once a client starts asking for more features. MFA, federation, auditing seem to inevitably become requirements at some point. If going with a third-party service, my advice would be to make sure you understand how to export the data out of the system, including hashed passwords using a non-proprietary algorithm.
MikeKusold 5y ago
> Auth providers cant help you because the passwords are hashed... You need the same algo or you cant authenticate using the data they have. You absolutely can migrate away from Auth providers. Auth0 (disclaimer: former employer) hashes passwords with Bcrypt, which is most likely the same exact algorithm you would choose. Bcrypt stores salts & rounds as part of the hash making those hashes fairly portable. Even if you wanted to change algorithms, there are ways to do this so that it is transparent to the user, such as running the plaintext password through a new algorithm after a successful authentication and storing it in a new column.
- mypalmike 5y ago
  He mentioned transparent migration and the problems encountered with it.
  - BoorishBears 5y ago
    > Auth providers cant help you because the passwords are hashed... You need the same algo or you cant authenticate using the data they have. Seeing as you have that it becomes a non-issue
    - mypalmike 5y ago
      Perhaps I'm incorrectly assuming auth providers don't expose an API for exporting all that data. Such an API would seem to be a fairly attractive attack vector.
      - systoll 5y ago
        Auth0 and fusionAuth don’t have APIs but will process requests manually.
throwaway894345 5y ago
> And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period. I would expect that the way to do this sort of migration is to run it until the costs associated with maintaining the migration infrastructure exceed the projected losses due to churn. You don't need to worry much about auth provider pricing because these are typically billed on the basis of monthly-active-users, so even if you have a small number of users who aren't active, they'll hardly show up on your bill. When this pool of unmigrated users is small enough that you can tolerate churning a percentage of them, you can turn off your migration infrastructure and enforce a hard password reset. That said, I don't know what kind of business has a significant percentage of users who churn because of a one-time password reset. I can't imagine any b2b contracts being canceled because the service provider enforced a password reset. Maybe retail sites are different?
Kenji 5y ago
Auth is simple. Even a script kiddie can do it. People who think auth is hard are amateurs. People who think auth should be outsourced are stupid.
rdevsrex 5y ago
I am on the side of not using one of these Auth companies, but if you are learning or just want to make a proof of concept fast, it definitely helps to have that taken care of for you.
lwhi 5y ago
Why not build in abstraction? If you have a middleware that lets you swap providers, you can start off with a ready made solution and switch if necessary. Obviously, this still means you need to maintain control over your data; but that's surely something a startup will do in any scenario, right?
- deleted 5y ago
  [deleted]

ocdtrekkie 5y ago

It is probably true that outsourcing your authentication to another party is probably bad, you probably should not write your own. So you should likely use a package for your auth code written by someone who focuses heavily on that.

AlchemistCamp 5y ago
In Elixir-land we're lucky. Jose Valim took his experience from writing Devise (the dominant Ruby gem for auth) and made auth generators for Phoenix apps! You own the user table, but the auth logic is written by an expert.

void_mint 5y ago

> Never outsource Auth. Maintain control over user accounts. This is some of the worst advice I've ever seen on HN. Don't take on risk you don't understand and cannot afford to mitigate. Don't be the next Equifax.

troygoode 5y ago
100%. I'm old enough that when I started my career we were still storing credit card numbers on our servers (and many companies were unfortunately doing so in the raw...). PCI compliance luckily knocked some sense into the industry. Crazy to me that some people don't realize that PII and secrets like passwords are basically in the same category now.
Raed667 5y ago
It is really not difficult to use BCrypt or Argon2 with your backend of choice. Proper password and session management have been made accessible for many years if you use any "modern" backend.
- void_mint 5y ago
  > Its really not difficult Good luck to you!
- city41 5y ago
  It's true the happy path and common error cases are easy to account for. But it just takes one overlooked bug or vulnerability either in your code or a library's code to send it all crashing down.
  - arcbyte 5y ago
    This is true across the board. One tiny crack in a bridge might mean it will collapse. That doesn't mean we should stop building bridges.
    - void_mint 5y ago
      Sure, but it certainly means we should leave bridge building to those who are experts in that field.
- bhaney 5y ago
  > It is really not difficult to use BCrypt Something I once saw in production: An otherwise normal usage of bcrypt, that "prehashed" the password with sha512 before passing the resulting hash to bcrypt. This is conceptually reasonable (although not very useful) for reasons I don't think are worth going into, but had two critical problems. 1. It technically broke bcrypt's side-channel protection against timing attacks (bcrypt runs in constant time, while sha512 does not). 2. The much worse issue was that the binary hash was being passed to bcrypt. If bcrypt encounters a null byte in the input, it considers that to be the end of the input and ignores everything after, c-string style. Every byte of the binary hash had a 1/256 chance of being a null byte, which means 1/256 passwords result in a hash with the first byte being null, which means bcrypt will accept any of them as equivalent to the others. You could login to 0.4% of accounts by guessing ~256 completely random passwords (and a larger number of passwords were similarly but less extremely weakened) You can say "well that's their fault for mucking with the input to bcrypt" but I bet most people would believe that kind of operation was safe before it's explained to them why it's not. It's very easy to accidentally destroy the security of a crypto scheme without knowing it, and thinking that what you're doing is perfectly run of the mill and safe.
dvdkon 5y ago
In what scenario do you need to have personal info associated with accounts and don't need to have full access to it? I see no user privacy benefits to outsourcing auth, unless all you need is to do is to verify someone's a real person.
guiomie 5y ago
But he's arguments are pretty sound to me. Do you have any counter-arguments than a generic statement?
- jayd16 5y ago
  I guess the question is what's more likely, Facebook, Google or Apple leaving the oauth game or a bug in an internal solution.
  - bryanrasmussen 5y ago
    what's more likely - you being able to talk to Facebook, Google, or Apple to let your app/site use their authorization solution once their algorithm has decided to ban you, or you fixing your bug.
  - capableweb 5y ago
    You're missing the original point. rgbrenner is talking about auth solutions like Auth0 where users can use username + password to sign up/login, and when you eventually are gonna have to leave (which, if your business is successful, you eventually will), you'll need to reset passwords one way or another. Of course, if you only use third-party authentication for your service, it doesn't really matter what's in-between there, you can work around it.
  - habibur 5y ago
    That they will ban you for one reason or other has a very high possibility of occurring before you go out of business.
    - jayd16 5y ago
      You and I have different definitions of very high possibility.
      - withinboredom 5y ago
        I had an app get banned for copyrighted content by Google because there was a movie poster in one of the backgrounds of the screenshots (camera type app in 2013). It will happen, probably for something ridiculous. In every job I’ve worked at, it had happened or they’d been threatened to be banned, at least once.
remram 5y ago
I don't think the main problem with Equifax was the Auth info they lost. It was their own business data, e.g. social security numbers etc, which wouldn't have been outsourced to their Auth provider anyway.
debaserab2 5y ago
This is literally the Auth0 first contact sales pitch designed precisely to scare you out of even trying to assess the risk of building it yourself. The reality is, though, it's never been easier than it is today to build secure auth - yes, it's still hard to do it right - but less hard than it ever has been before. So many security features are now a checkbox on a cloud provider's web interface that would have been a manual implementation of the underlying protocol a decade ago. So many languages have matured battle-tested OS libraries for handling the especially sensitive parts like crypto. This notion that it is a "no-brainer" decision to happily trade your customer database and a % of revenue to remove the burden of stewardship seems crazy to me.
- deergomoo 5y ago
  Not to mention there’s a whole lot of middle ground between writing your own auth logic and using a hosted service. Any reasonably popular web-oriented language has plenty of fully featured, high quality libraries you can often just drop in. Hell, we use Laravel at work, which includes pretty robust auth features out of the box. It feels like such table stakes stuff for a web framework that I find the idea of paying for a third-party cloud service absolutely bananas. It also includes pretty solid notification and payment solutions too, though these usually plug into services like SNS and Stripe and don’t really fit the “self hosted” bill.
  - beardbandit 5y ago
    I think that's where the confusion lies. Are people suggesting someone to write their own auth from the ground up, or write auth in coordination with their stack's auth library of choice?
    - joshmanders 5y ago
      It appears to me the assumption these people / articles make is that nobody is using existing hardened production ready libraries, but hand writing everything from the ground up for their todo app. Because otherwise their message falls flat on its face.
justinclift 5y ago
Well, we implemented Auth using Auth0. The experience wasn't terrible, but not fantastic either. Probably best described as "ok". However, now they've been bought by Okta, which has a pretty bad reputation. So, I guess we'll get to find out eh?

AlexSW 5y ago

Using the same authentication algorithm doesn't seem like a particularly big price to pay, assuming they started with a sensible one. And there's nothing stopping one from making it support the old style but add a more up-to-date algorithm for new password sets, either.

deleted 5y ago

[deleted]

chaostheory 5y ago

You can do both. Just use an open source project for auth instead of reinventing a commodity wheel.

mooreds 5y ago

You can also choose to self host. Keycloak and FusionAuth (disclosure, I am an employee) let you self host. You then have the user database in your systems. > And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period. Actually, not true. I can't speak for every auth provider, but FusionAuth and Auth0 both let you have the password hashes. If you know the algo (ask your provider!), you can load the hashes (and other ancillary password data like the salt) and your users will never be the wiser. Here's a guide I wrote about how to migrate off of Auth0: https://fusionauth.io/docs/v1/tech/guides/auth0-migration/ https://fusionauth.io/docs/v1/tech/guides/auth0-migration/ The end goal of the guide is to move to FusionAuth, but the steps to get your password hashes out of Auth0 (the 'Exporting Users' section) will work no matter where you migrate to.

rvense 5y ago
I'm currently implementing Keycloak for my startup. It's not perfectly documented, but I really like all the things it can do for us and how extensible it is.
- mooreds 5y ago
  I'd suggest checking out FusionAuth, but I'm a bit biased :) . I have heard good and bad things about Keycloak, but I know one thing for sure: it's far better than rolling your own auth. Good luck with your startup!
  - outime 5y ago
    I understand that you want to promote your solution and you have a disclaimer in the previous comment - and that's great. But if you keep insisting then you should IMHO at least provide some reasons on why your solution may be better than e.g. Keycloak and not just posting the name a couple times and see if it sticks.
    - 5y ago

remram 5y ago

Making people reset their password is not that big of a deal. I have run into this multiple times, the most recent being amtrak.com. It just told me "you have to reset your password" and I got a link in email like if I had forgotten it. I have also received many "we had a security incident you have to reset your password now" emails in recent years.

sam_lowry_ 5y ago
There is a whole line of thought that accounts should be passwordless and accessed via an email reset link as part of normal login procedure.
- slavboj 5y ago
  Which is great until you lose access to your email.
  - em-bee 5y ago
    if you loose access to your email, you may just be out of luck. a good service will not allow you to change your registered email address without verifying that you own the old one
    - yawaramin 5y ago
      Not in my experience. Every account I can think of allows me to change my email address without verifying the old one.
  - dstick 5y ago
    And how would you even login to your email using that method :)
- jedberg 5y ago
  Yeah I hate that method. It's good in theory but terrible for the user. I go to a website I want to use. I click the magic link. The email takes 10 seconds to show up. In that 10 seconds I find something else to do while I'm waiting. I get distracted and find the magic link in my email 10 minutes later. It's now expired and I have to start over. Or just give up. With a password, I click the site I want to use, my password manager fills in the password for me, and I click "login" and bam, I'm done.

unethical_ban 5y ago

It's one thing to host your own/maintain your own auth database, but there is a definite benefit of using a tool like Okta SSO to link your authn to other services, if that's your business.

patwolf 5y ago

I've built auth systems from scratch and used third party auth services. Doing it from scratch always feels reasonable at first when it's just basic username and password, But I start to regret it once a client starts asking for more features. MFA, federation, auditing seem to inevitably become requirements at some point. If going with a third-party service, my advice would be to make sure you understand how to export the data out of the system, including hashed passwords using a non-proprietary algorithm.

MikeKusold 5y ago

> Auth providers cant help you because the passwords are hashed... You need the same algo or you cant authenticate using the data they have. You absolutely can migrate away from Auth providers. Auth0 (disclaimer: former employer) hashes passwords with Bcrypt, which is most likely the same exact algorithm you would choose. Bcrypt stores salts & rounds as part of the hash making those hashes fairly portable. Even if you wanted to change algorithms, there are ways to do this so that it is transparent to the user, such as running the plaintext password through a new algorithm after a successful authentication and storing it in a new column.

mypalmike 5y ago
He mentioned transparent migration and the problems encountered with it.
- BoorishBears 5y ago
  > Auth providers cant help you because the passwords are hashed... You need the same algo or you cant authenticate using the data they have. Seeing as you have that it becomes a non-issue
  - mypalmike 5y ago
    Perhaps I'm incorrectly assuming auth providers don't expose an API for exporting all that data. Such an API would seem to be a fairly attractive attack vector.
    - systoll 5y ago
      Auth0 and fusionAuth don’t have APIs but will process requests manually.

throwaway894345 5y ago

> And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period. I would expect that the way to do this sort of migration is to run it until the costs associated with maintaining the migration infrastructure exceed the projected losses due to churn. You don't need to worry much about auth provider pricing because these are typically billed on the basis of monthly-active-users, so even if you have a small number of users who aren't active, they'll hardly show up on your bill. When this pool of unmigrated users is small enough that you can tolerate churning a percentage of them, you can turn off your migration infrastructure and enforce a hard password reset. That said, I don't know what kind of business has a significant percentage of users who churn because of a one-time password reset. I can't imagine any b2b contracts being canceled because the service provider enforced a password reset. Maybe retail sites are different?

Kenji 5y ago

Auth is simple. Even a script kiddie can do it. People who think auth is hard are amateurs. People who think auth should be outsourced are stupid.

rdevsrex 5y ago

I am on the side of not using one of these Auth companies, but if you are learning or just want to make a proof of concept fast, it definitely helps to have that taken care of for you.

lwhi 5y ago

Why not build in abstraction? If you have a middleware that lets you swap providers, you can start off with a ready made solution and switch if necessary. Obviously, this still means you need to maintain control over your data; but that's surely something a startup will do in any scenario, right?

deleted 5y ago
[deleted]