Comment by ipnon
11 hours 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.
11 hours 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.
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.
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.