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

141–150 of 193 posts

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

#141

Post by m0llusk »

Never is a really big qualifier. It is possible for practiced coders to build secure systems. This is how we get trusted systems.

Trusting auth systems is always a gamble. Remember when Google 2FA was only actually checking the first factor? I sure do.

In my business the simple account and password ID model is insufficient. Most of our accounts are for families or organizations with complex contact protocols. Because on site service is the product we have the luxury of extensive physical in person verification. Assuming that every auth issue is for a typical Internet SaaS is a huge mistake.

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

#142

Post by bluefirebrand »

mooreds wrote: post #118
outime wrote: post #111

Earlier quoted context omitted.

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.

Fair point. Here's what I'd say if someone was choosing between Keycloak and FusionAuth: I believe that FusionAuth has a better developer experience. Everything is an API, the docs are regularly updated (though we can always do better). There's an easy way to set up developer environments to a known state (Kickstart) that I don't believe Keycloak has an analog for. FusionAuth supports limited memory environments. We…

You convinced me. I've been eyeballing Keycloak, will definitely give FusionAuth a shot first. :)

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

#143

Post by sethammons »

Anonashtonian wrote: post #75

No. Auth is not that hard, it's not hard to scale. It's the bloodline of every interaction between you and your customers. Nearly every "web" language has a open source Auth solution with modern jwts or jwts on cookies. Bcrypt and salting solves "storing passwords". Further more once you do it it's highly repeatable across products.

exactly. Don't be clever and try to do things like re-invent bcrypt or hmac or do things through obscurity. Use the libs. I've written many auth systems, it is not rocket surgery. It is one of those things where you need to do some reading and understand what is going on, but I'd argue you should do that for just about everything you are working on.

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

#144

Post by nicoburns »

bhaney wrote: post #101
arcbyte wrote: post #84

Earlier quoted context omitted.

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.

My point is precisely that it wasn't "monumentally stupid," but rather a pretty reasonable decision given what the average person would expect bcrypt to provide functionally. The behavior I described is an unexpected landmine that people using bcrypt need to be aware of. There are likely others, though probably not enough that I would describe it as a minefield. I would wager that most people reading this, if earnest…

My answer would definitely be: I don't know, but why bother. We know bcrypt by itself works. We don't know whether it works combined with another hash, and it's extra code we need to maintain.

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

#145

Post by NicoJuicy »

A lot of people are talking about auth/jwt.

I'm wondering for those who build it:

- how did you implement impersonation

- how did you implement tenants ( and switching in between). Most have a follow-up dialog after logging in, which you can select.

- did you implement something in your gateway that checks the token, instead of every service separately ( too lighten the load to the STS)

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

#146

Post by doctor_eval »

Raed667 wrote: post #36
jchw wrote: post #16

Crap, I’ve done all three! Well, maybe not all at once though. I can see why not to do notifications, but it’s hard to avoid doing some form of it if you’re making an app with focus on low latency realtime updates. The bigger problem is that out of all three categories, I only really feel content with trusting Stripe, and only so much. Auth0 has its issues, and decent authentication systems you can roll on your own a…

I'm curious how people handled payments before Stripe? Did you integrate with banks directly? How different is that in terms of what Stripe offers?

You would typically integrate with a gateway who integrates with one or more banks who integrate with the schemes to get global coverage.

There are generally a number of domestic gateways in each region (I’ve worked with gateways in Australia, Malaysia and a couple of other places) but there are also larger providers.

There are name brands like Braintree and lesser known but still quite large, like Adyen. The API quality is extremely variable.

Checking out multiple gateways is a good idea. Stripe is supposed to be great but IIRC is relatively expensive.

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

#147

Post by mooreds »

bluefirebrand wrote: post #142
mooreds wrote: post #118

Earlier quoted context omitted.

Fair point. Here's what I'd say if someone was choosing between Keycloak and FusionAuth: I believe that FusionAuth has a better developer experience. Everything is an API, the docs are regularly updated (though we can always do better). There's an easy way to set up developer environments to a known state (Kickstart) that I don't believe Keycloak has an analog for. FusionAuth supports limited memory environments. We…

You convinced me. I've been eyeballing Keycloak, will definitely give FusionAuth a shot first. :)

Awesome, would love to hear how it goes.

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

#149

Post by PeterisP »

swiley wrote: post #3

Letting other people handle Auth and Notifications is a great way to get the rug pulled out from under you.

There's a big gap between "never build yourself" and "letting other people handle it". Yes, you should have full control over your auth, run it yourself and keep the data - but you still should not build it yourself, you should use well-established solutions/libraries built by others instead of trying to figure out e.g. what's the proper way to salt passwords.

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

#150

Post by BoorishBears »

mypalmike wrote: post #136
MikeKusold wrote: post #98

Earlier quoted context omitted.

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

> 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

Post reply on HN