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

131–140 of 193 posts

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

#131

Post by rdevsrex »

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

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

#132

Post by lwhi »

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…

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?

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

#133

Post by dhbradshaw »

It's been said a few times here, but it's important so I'm calling it out on the top level:

Don't roll your own auth. But do feel free to use a battle tested auth library / or framework hosted in your own app.

Then you get both benefits: 1. You don't have to put your destiny in someone else's hands, and 2. You're not getting the risks associated with building your own auth.

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

#134

Post by mooreds »

beachy wrote: post #120
mooreds wrote: post #81

Earlier quoted context omitted.

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!

I've never checked out your product, but we use Keycloak extensively and I can say it is a great Auth solution and I've used several and even built some (poorly). The only real downside of Keycloak IMO is the documentation. Because it covers so many bases, and is very extensible, the official doc is enormous. There are a lot of lightweight articles about how to use it, I'd use one of those to get started. Some great…

Awesome, appreciate the perspective. A few qs for you:

My understanding is that you ended up writing java code to extend keycloak. Is that wrong?

Is keycloak resource hungry or have I heard wrong? Have you tried keycloak X? Is that better?

Is there a way to configure a dev environment? Is Terraform the preferred IaC solution?

How many realms do you use typically?

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

#135

Post by withinboredom »

jayd16 wrote: post #100
habibur wrote: post #94

Earlier quoted context omitted.

That they will ban you for one reason or other has a very high possibility of occurring before you go out of business.

You and I have different definitions of very high possibility.

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.

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

#136

Post by mypalmike »

MikeKusold wrote: post #98
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…

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

He mentioned transparent migration and the problems encountered with it.

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

#137

Post by GormanFletcher »

kelnos wrote: post #130
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…

> 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. What makes you think this foolish developer would not do the exact same thing before sending the data to an externally hosted auth service?

The external auth service's API would receive textual input (expecting a string read from a textbox), not binary. A hash that included null bytes would output those in hex as ASCII zeroes, which wouldn't cause the same problem when the external service received the value.

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

#138

Post by [deleted] »

lwhi wrote: post #132
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…

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]

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

#139

Post by gentleman11 »

wisemanwillhear wrote: post #34
capableweb wrote: post #18

More general: Things to never build yourself: Things outside your core business. Are you selling a notification service? Build it yourself, otherwise find either self-hosted or hosted solutions, depending on situation.

I've always thought this statement from Martin Fowler was right on target. > Boiled down this means that if the business process you are supporting is part of your competitive advantage you should build custom software, if not you should buy a package and adjust your business process to fit the way the package works. Source: https://martinfowler.com/bliki/PackageCustomization.html

There’s nothing I dread more than customizing software, and then having the supplier release a critical update that requires you to re-do the work and search for bugs. It’s so expensive and error prone, it really is just better sometimes to treat your version as a hard fork or else make your own system

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

#140

Post by colinclerk »

debaserab2 wrote: post #74
void_mint wrote: post #39

Earlier quoted context omitted.

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

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…

> but less hard than it ever has been before

I have a very vested interest in this (founder Clerk.dev) - but the exact opposite experience is what led us to start Clerk.

Auth was easy when it was just email verification and choosing the right hashing algorithm. I used to pull Devise off the shelf and get it going in 30 minutes.

But these days, the simple solution is far from complete. I grew most frustrated trying to setup the rest...

- Single sign-on / Oauth with proper de-duping so users can always sign in regardless of how they signed up

- 2fa so users can better secure their accounts

- Integrations with a leaked password corpus (haveibeenpwned) to prevent credential stuffing attacks

- Active device tracking and remote session revocation

You can launch without these things, but it's definitely impacting your overall security and the conversion rates through your sign up and sign in flows.

Post reply on HN