11 ms·

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.

by ipnon 4mo ago

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

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.

by ipnon 4mo 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 4mo 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 4mo ago
> and one where the password lockout system meant that you could DDoS all admin access trivially What happened there?
- SahAssar 4mo 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 4mo 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 4mo ago

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

Orygin 4mo 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 4mo ago

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