Hacker News Reader

Comment by JSR_FDED | Hacker News Reader

So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth.

Knowing every single line of code involved allowed me to add some location-based functionality for one client, provide tailored logging to meet the needs of another client, and my favorite was winning a deal against much bigger competitors by being able to integrate with an absolutely ancient legacy system.

Just like “Goto considered harmful”, DRY, YAGNI, etc - they’re great at making you slow down and think. But they’re not inviolable.

View on HN

Kind of funny how something that used to be routinely self-written has been outsourced to libraries. I must’ve written auth like a few dozen times back in the PHP days, not particularly hard or complicated. There’s a million tutorials on how to salt and store passwords. I’ve had my sites attacked many times, but never breached. (JWT, OAuth, etc. has added a ton of surface area, however. So these days it’s inevitably harder to do.)

And now the libraries have been outsourced to saas companies because ???

Because we need to move faster and cheaper, that's the future

Username and password as the only option to authenticate is really getting obsolete. You need to support social login, passkey, email links, maybe SMS or some other less secure methods depending on your target market… and more often also new standards like verifiable credentials with wallets managing credentials, including logins. Good luck writing your own implementations.

It's not that crazy. It can take time to do and get right, and is time away from other things.

Even if done for fun/learning, it can teach how the details of auth work to better appreciate and understand how other systems work and what to look out for.

I prefer to use existing things if possible, but if it was getting unreasonable to get it how it was needed, it wouldn't be off the table.

It’s not that crazy! Or hard. If you can store a hashed password in your users table, and keep the salt secret, you have working auth.

I'm not discouraging anyone from writing your own auth, but if you have even a little bit higher requirements it becomes more complex. For example I have audited codebases where the TOTP code was enough to get a valid token (without a password, due to a bug), where there was no rate limits on password attempts and one where the password lockout system meant that you could DDoS all admin access trivially, etc, etc. That's even before you need to integrate with a third party via something like OIDC or SAML or SCIM which are probably needed for a product used by businesses these days.

It is hard for serious use-cases. That does not mean you should not do it, but know what tradeoff you are doing in the build-vs-buy equation. Know that this part of your system probably requires more testing, review and expertise than your core product.

> and one where the password lockout system meant that you could DDoS all admin access trivially

What happened there?

Password attempt lockouts where not scoped to anything besides the account itself. By just spamming a few attempts per account you could lock all admin accounts meaning that there was no admin to unlock the other accounts.

The only solution in such a case would be to manually remove the lockout flags in the db.

Cookie management and CSRF stuff harder to get right, hashing passwords is completely trivial with and library.

And the cookies are not difficult on a technical level, you just have to spend time understanding the threat models and mapping those models correctly onto your own app.

And then the client asks for SAML & OIDC support, and codes via SMS, and god knows what else.

Indeed. Password auth was always easy to do, and it seems half the commenters here think that's all you need in modern times.

Then customers come and ask for SSO, SAML, OIDC, their niche auth protocol, 2FA, Pass phrases, etc...

And now your auth is a mess and a dedicated job to maintain and evolve.

If you believe salt has to be kept secret, yeah, don't write your own auth.

I'm actually surprised val.town outsources it. So what you're doing makes sense to me.

I recently worked at a stupid startup where the entire logic of the app was basically delegated to several third-party services out there. It felt like an absolute piece of shit overall. Following the flow of things end-to-end was a nightmare. It was so stupid because the so-called co-founder PM at that company thought it would be cool to keep doing that.

I am with you on this.

Thats because the goal of the start-up is to prove they have a viable business not build fancy tech.

At the same time, it also made things three times more complicated when it came to debugging. They found themselves swimming in the shit

Reply on news.ycombinator.com