5 ms·

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 scienc

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.

ipnon 6mo ago
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.
- SahAssar 6mo ago
  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.
  - Capricorn2481 6mo ago
    > and one where the password lockout system meant that you could DDoS all admin access trivially What happened there?
    - SahAssar 6mo ago
      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.
- skrtskrt 6mo ago
  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.
- LVB 6mo ago
  And then the client asks for SAML & OIDC support, and codes via SMS, and god knows what else.
  - Orygin 6mo ago
    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.
- gkoz 6mo ago
  If you believe salt has to be kept secret, yeah, don't write your own auth.
j45 6mo ago
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.
dvt 6mo ago
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.)
- rozap 6mo ago
  And now the libraries have been outsourced to saas companies because ???
  - ramon156 6mo ago
    Because we need to move faster and cheaper, that's the future
- brabel 6mo ago
  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.
princevegeta89 6mo ago
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.
- Urahandystar 6mo ago
  Thats because the goal of the start-up is to prove they have a viable business not build fancy tech.
  - princevegeta89 6mo ago
    At the same time, it also made things three times more complicated when it came to debugging. They found themselves swimming in the shit
benatkin 6mo ago
I'm actually surprised val.town outsources it. So what you're doing makes sense to me.

ipnon 6mo ago

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.

SahAssar 6mo ago
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.
- Capricorn2481 6mo ago
  > and one where the password lockout system meant that you could DDoS all admin access trivially What happened there?
  - SahAssar 6mo ago
    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.
skrtskrt 6mo ago
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.
LVB 6mo ago
And then the client asks for SAML & OIDC support, and codes via SMS, and god knows what else.
- Orygin 6mo ago
  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.
gkoz 6mo ago
If you believe salt has to be kept secret, yeah, don't write your own auth.

j45 6mo ago

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.

dvt 6mo ago

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

rozap 6mo ago
And now the libraries have been outsourced to saas companies because ???
- ramon156 6mo ago
  Because we need to move faster and cheaper, that's the future
brabel 6mo ago
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.

princevegeta89 6mo ago

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.

Urahandystar 6mo ago
Thats because the goal of the start-up is to prove they have a viable business not build fancy tech.
- princevegeta89 6mo ago
  At the same time, it also made things three times more complicated when it came to debugging. They found themselves swimming in the shit

benatkin 6mo ago

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