Three things to never build yourself: auth, notifications, payments • Hacker News Board

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

#161

Post by wepple » Fri, May 14, 2021, 12:32 AM UTC

bokohut wrote: post #123

As a serial entrePAYneur and the core foundational member of multiple payments companies responsible for all hardware and software architected, assembled and constructed with my very own hands I would sternly disagree with this article. I have done exactly what this article states not to do and have done so multiple times with each better than the last, it only takes an interest and an insatiable desire to learn. The…

> As a serial entrePAYneur

I don’t follow

> core foundational member of multiple payments companies

If you’re building a payments company, your product is literally doing the payments yourself!

> with each better than the last,

So, the first ones weren’t very good huh? Perhaps you could have outsourced them?

> Security will become paramount to everything and outsourcing for "cheap" will have a much greater cost than one realizes in the moment.

You’re conflating the use of a 3rd party for cost reduction with using a 3rd party due to efficacy and efficiency due to specialization. There’s zero chance you’re as good at Auth as a whole team of security engineers at an auth provider, period.

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

#162

Post by beachy » Fri, May 14, 2021, 12:35 AM UTC

mooreds wrote: post #134

beachy wrote: post #120

Earlier quoted context omitted.

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?

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

Depends what you mean by "extend". For many operations, there are REST APIs, e.g. to create a realm (somewhat equivalent to a tenant in the SaaS world - though see below), it's simply POST /auth/admin/realms. There are also more elaborate extensions such as login listeners that if I remember correctly, you would build in Java, but we don't need those.

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

We haven't found it to be disproportionally resource hungry at all. I'm sure there are scenarios we haven't exercised but resource usage not a problem for us. Not fond of the way vendors throw around allegations like that without hard facts.

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

Depends on your own preferences, we just bring it up in a docker container.

> How many realms do you use typically?

Everyone will skin this cat differently, but for us (SaaS):

- one big realm that most tenants use.

- one admin realm for trusted internal access (i.e. our support team).

- one big realm that candidates use (we are an HR platform)

- one realm per tenant that needs SSO. e.g. if they want to authorise login using their own GSuite account, they get their own realm with their own idp.

As someone else pointed out, having large numbers of realms is a weak point of Keycloak. I look forward to us having enough SSO clients that that becomes a problem for us :)

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

#163

Post by beachy » Fri, May 14, 2021, 12:37 AM UTC

ozymandias12 wrote: post #128

beachy wrote: post #120

Earlier quoted context omitted.

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…

What other FOSS like Keycloak we have available in 2021? Looking to update my knowledge on options

There is ForgeRock and WSO2 which we have used in the past. Perhaps they have moved on but would not recommend vs Keycloak.

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

#164

Post by judge2020 » Fri, May 14, 2021, 12:59 AM UTC

cblconfederate wrote: post #159

I often wonder why startup devs earn such high salaries if apparently they outsource everything, and are very opinionated about it, and have the quotes from business gurus to support those opinions.

Connecting things to the correct parts of other things can be just as messy and difficult as writing code :)

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

#165

Post by justinclift » Fri, May 14, 2021, 1:09 AM UTC

void_mint wrote: post #39

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…

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

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?

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

#166

Post by zzt123 » Fri, May 14, 2021, 1:09 AM UTC

colinclerk wrote: post #140

debaserab2 wrote: post #74

Earlier quoted context omitted.

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…

I found these features quite simple to implement. What gave me a headache was advanced anomaly detection (both from the per-account and per-requester perspectives) and handling. For me, there is no bottom of the well on those things, and they are the killer features of auth as a service.

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

#167

Post by edmundsauto » Fri, May 14, 2021, 1:22 AM UTC

sam_lowry_ wrote: post #106

jpm_sd wrote: post #73

I'm a hardware designer, apologies if this is a dumb question about "auth". If you're creating a product that is primarily or exclusively for mobile devices, what's the downside of relying on "log in with Google" and/or "sign in with Apple"?

Some people would not login then, and a vocal minority will complain loudly.

For your business, this may be a positive overall.

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

#168

Post by yawaramin » Fri, May 14, 2021, 1:40 AM UTC

em-bee wrote: post #152

slavboj wrote: post #102

Earlier quoted context omitted.

Which is great until you lose access to your email.

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

Not in my experience. Every account I can think of allows me to change my email address without verifying the old one.

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

#169

Post by brailsafe » Fri, May 14, 2021, 2:35 AM UTC

As a frontend developer, I've been wanting to expand my skills as a server-side developer, and have been a little lost on where to get started in building an auth system, and how I'd approach deeply understanding it enough to do it right (regardless of whether it's the right business choice or not, it seems likely worthwhile to be able to do it). Does anyone have any good resource that would provide a robust exploration into building this kind of system, either in a specific language or just a general one? I'm talking sane abstractions that you'd see Fowler talking about, and something that I could actually follow while writing code to do it.

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

#170

Post by bhaney » Fri, May 14, 2021, 2:37 AM UTC

jlokier wrote: post #154

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…

Your point 1 seems wrong. SHA-512 is constant time for any reasonable password length and any reasonable implementation. It hashes 1024-bit blocks in constant time, as it only uses 64-bit word operations such as add, shift, xor etc in a fixed order with fixed constants. There are no input data-dependent lookups, or other variable-time operations. If you are considering the string copy that happens when the unhashed p…

> Your point 1 seems wrong. SHA-512 is constant time for any reasonable password length and any reasonable implementation.

I'm aware of this, and it's why there's a "technically" in my original point. Of course in practice it makes no difference, and I consider the better use of bcrypt's input space when prehashing to outweigh leaking a pretty useless amount of side-channel information for extraordinarily long passwords.

Though as a follow up anecdote, one of the engineers there had set a 300kB password to test the prehashing implementation, and just continued to use it (via password manager). He was potentially leaking a bit of timing information. I'm not even sure if a password that long made a timing difference that was detectable through network jitter, but if it did and some hypothetical attacker was able to learn that his password was hundreds of kilobytes long, well... good luck.

> in fact I use: SHA-512 -> Base64 -> bcrypt when password hashing. Does that make me wrong?

No, using a base64 representation of the sha hash makes your scheme perfectly reasonable. Also note that the base64 representation of sha512 is a bit longer than the typical bcrypt input length, so you're shrinking the collision space somewhat by truncating your sha hash. Certainly not enough that it would matter at all, just a point I find interesting. Hypothetically, a binary representation with a pass that removed or replaced NUL bytes would preserve more entropy, but we're well past the point where it matters and would be playing with fire to consider that complexity.