Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three things to never build yourself: auth, notifications, payments

courier.com

Post reply on HN
Print view View original

81–90 of 193 posts

Re: Three things to never build yourself: auth, notifications, payments

#81

Post by mooreds »

rvense wrote: post #77
mooreds wrote: post #48

Earlier quoted context omitted.

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 sp…

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.

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!

Re: Three things to never build yourself: auth, notifications, payments

#82

Post by sam_lowry_ »

remram wrote: post #66
rgbrenner wrote: post #27

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…

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.

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.

Re: Three things to never build yourself: auth, notifications, payments

#83

Post by bryanrasmussen »

jayd16 wrote: post #76
guiomie wrote: post #57

Earlier quoted context omitted.

But he's arguments are pretty sound to me. Do you have any counter-arguments than a generic statement?

I guess the question is what's more likely, Facebook, Google or Apple leaving the oauth game or a bug in an internal solution.

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.

Re: Three things to never build yourself: auth, notifications, payments

#84

Post by arcbyte »

bhaney wrote: post #78
Raed667 wrote: post #53

Earlier quoted context omitted.

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.

> 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…

Thank you for sharing that experience. It was a very interesting read.

However, lest anyone get the wrong opinion, password hashing is a very simple, straightforward, solved problem and has been for years.

One person doing something monumentally stupid doesn't make Auth some kind of cryptic minefield.

Re: Three things to never build yourself: auth, notifications, payments

#85

Post by noAnswer »

remram wrote: post #66
rgbrenner wrote: post #27

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…

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.

You sure it wasn't phishing. SCNR

Re: Three things to never build yourself: auth, notifications, payments

#86

Post by capableweb »

jayd16 wrote: post #76
guiomie wrote: post #57

Earlier quoted context omitted.

But he's arguments are pretty sound to me. Do you have any counter-arguments than a generic statement?

I guess the question is what's more likely, Facebook, Google or Apple leaving the oauth game or a bug in an internal solution.

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.

Re: Three things to never build yourself: auth, notifications, payments

#87

Post by patwolf »

rgbrenner wrote: post #27

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…

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.

Re: Three things to never build yourself: auth, notifications, payments

#88

Post by remram »

noAnswer wrote: post #85
remram wrote: post #66

Earlier quoted context omitted.

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.

You sure it wasn't phishing. SCNR

Yes

Re: Three things to never build yourself: auth, notifications, payments

#89

Post by [deleted] »

arcbyte wrote: post #84
bhaney wrote: post #78

Earlier quoted context omitted.

> 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…

Thank you for sharing that experience. It was a very interesting read. However, lest anyone get the wrong opinion, password hashing is a very simple, straightforward, solved problem and has been for years. One person doing something monumentally stupid doesn't make Auth some kind of cryptic minefield.

[deleted]

Re: Three things to never build yourself: auth, notifications, payments

#90

Post by arcbyte »

city41 wrote: post #62
Raed667 wrote: post #53

Earlier quoted context omitted.

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.

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.

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.
Post reply on HN