And I mean SSO, persistence, cookies, hashes, network dropouts, OAuth, etc. Curious to get y'alls take on it!
Or are you implying using existing libraries or services instead of rolling out your own?
Man-in-the-Middle (MITM). I'm at the same coffee shop as you and I've taken control of the router. You request your bank's web site and I'm able to route that request through my laptop, fetch the web page, and return it back to you. You log in to the web site. The connection is still encrypted, but the termination of the encryption is actually happening on my laptop. You log into the bank site. I now have your bank account credentials.
Cross-site scripting (XSS). Your site allows visitors to embed content (for example, message board posts) without that content being properly filtered. I use that to embed some JavaScript that watches for users using the log in form on your site and send those credentials to me, or sends the content of the cookie of users already logged on.
Poor hashing. You mentioned that above so you're probably aware of it already, but it's disturbing and surprising how many sites don't have this figured out yet.
I'm not sure what problems network dropouts could cause, at least in terms of security - which is the big problem here.
Of course there's more, but this is what comes to mind. In summary, I strongly suggest you don't try to reinvent a new authentication system. use one already in common use. It's probably already fairly battle-tested and validated for correctness and security. This goes for most other types of software as well.
If you add caching (esp. to your auth-chain), you need automated tests covering every access pattern. Concurrent access, cache timeouts, cache full, cache invalidation, etc.
https://forums.overclockers.co.uk/threads/do-not-login-to-an...
Alex Stamos, former head of security at Facebook, described the security issues they got as a pyramid where the vast majority of issues were basic fraud, friend/family trust, fake login pages / fake emails, reused credentials, and email takeover. You won’t be able to help with most of these unless you can help your users change their behavior.
For the other stuff, use the best SDLC techniques, never commit secure strings to version control (assume your source repo is misconfigured), use 12 Factor principles, read OWASP docs, search for relevant HackerOne disclosed reports (or blog articles, CTF write ups). There is no amount of coding that can replace red team user testing / a security audit.
There are a bunch of good options out there - and all of them are likely better than trying to go it alone!
- OAuth 2 IdP and SP federation plus theming
- SAML v2 IdP and SP federation
- Nested federation (i.e. OAuth to SAML to OAuth to another OAuth)
- JWTs (issuing, validation, introspect, user_info, numerous certificate and key-pair concerns, reconciliation, introspection)
- Refresh tokens (managing, revoking, exchanging, securing, and more)
- Lambdas to handle claim mapping and JWT population plus all the security around sandboxing JavaScript so it isn't an attack vector
- Key management
- Certificate management
- User indexing and searching (when you have 100+ million users, this isn't easy)
- Password rules (HIPAA, PCI, SOC, ISO, NIST)
- Breached password detection (Have I been Pwnd style)
- Password hashing (making it configurable, changeable, upgradeable, etc)
- Devices (trust, OAuth Device Grant, MFA, passwordless)
- Threat modeling and detection
- Brute force prevention
- Account locking
- Event management (login, account creation, deletion, etc)
- CORS
- CSRF
- XSS
- Injection attacks (JS, SQL, etc)
- Privilege escalation attacks (tunnels, backdoors, script injection, etc)
- Replay attacks
- JWT header attacks
- Click-jacking attacks
- IFraming
- CVE management (libraries, OS, database, frameworks, APIs, etc)
- MFA (authentication apps and SMS)
- TOTP
- MITM and spoofing
- HSTS
- Passwordless logins
- Network management (firewalls, public and private access, intrusion detection, logging, auditing)
- Pen tests (i.e. these aren't cheap)
- Compliance (also not cheap and very time consuming)
- Family management (multiple parents, divorces, multiple kids, roles, ages, consents)
- Consent modeling (CCPA, GDPR, and many more are coming)
- Group management
- Roles and permissions
- All the email things (forgot password, passwordless, email verification, templates, localization)
- Reporting (DAU, MAU, etc)
Every line of code, every API, every HTML page, every button click, every form submit, every layer, every network hop, every operating system, every third-party tool, every library, and every browser must be secured and tested. If you have a big team and a lot of free time, you can probably get something workable that is secure in a year or two.
Of course, YMMV. ;)
Or like other folks have said, you can always use FusionAuth, Keycloak and others. They are all free and do all of this already. Though, I'd be suspicious with some projects. The compliance, auditing and testing pieces are expensive and probably not something they do much of.
And who knows what is going on with IBM and RedHat. I'd run screaming from that disaster if I were you. :)