Stop implementing local account systems. Implement SSO protocols and leave authentication to those specialized for it.
@sheogorath Personally I'd prefer people implemented passwordmanager-backed publickey authentication!
Asking devs to implement SSO protocols lends itself to them requiring me to have an account services I don't want!
@toe @sheogorath Password stores on free desktops (GNOME & KDE) supports storing crypto keypairs. Password managers like Bitwarden support syncing them so you can access your pubkey-authenticated accounts from any of your computers.
The point of the excellent security & decentralization of pubkey authentication without the single-device limitation!
@iron_bug To have proper account recovery, MFA, password guidelines (if required), secure storage for passwords, rate-limits, audit logging, …
All of that without the requirement to implement it for each and every application.
And there are many many implementations for IDPs, some are proprietary, others are open source, so no need for "centralized proprietary crap".
@iron_bug Account recovery exists for decades and yet, a lot of software is bad at it.
How is "software implementing standard SSO protocols" spyware?
"…what's the difference with any other realization?" You have specialised software that does the account management for you. Not every software has to implement MFA, password policies, … Even custom account recovery flows like asking Steve from HR or a child's mother nothing apps have to worry about.
@iron_bug You library can only do that much. Look at the open source world that implements Username + Password and how many of it, support WebAuthn. Every application that talks OIDC, SAML or just plain oauth2, can immediately utilise WebAuthn if my IDP deploys it.
@iron_bug Even further you eliminate the potential for entire classes of common problems, like insecure password storage, missing rate limits on authentication endpoints, missing audit logging for authentication events, …
A lot of things listed here: https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/
Have one specialised application deployed that takes care of all of it, everything else, just use standard SSO protocols, done.
> imposing everybody to use one realization
Not really what I do. There are multiple SSO protocols, there are an uncountable number of IDPs, there any many implementations, standards and providers for each level of the implementation.
And by no means does SSO imply storing user credentials by an **unknown third-party**. You store it by an IDP of your choice, which might even be yourself.
@iron_bug And of course CWEs don't exist in a vaccum, but try use a default passwords if there is no place to enter them, because you don't do authentication in your application. Also there is no "forgot your password" process in your application, another thing you can't mess up.
You see what I try to say?
@iron_bug Client certificates are one from of MFA. MFA is not limited to username+password in combination with some third-party.
Despite that, reality is, that mTLS is just not super practical for most people. The more practical implementation which also finds adoption is WebAuthn, which also has some other benefits. Even though it doesn't use RSA, because why use large, slow keys?
@iron_bug Well, you'll still need to refer to third-party servers unless you want to ignore certificate revocations. Of course you can argue, that you deploy CRLs on all servers as soon as one takes place, but then you scale this up a bit, or have devices that don't always have connection to the network and things begin to explode.
@sheogorath I mostly agree.
But rather than having each and every application reinventing the wheel with their own (SSO) authentication, I'd prefer to see adoption of solid, well-written and well-vetted building blocks that take care of the authentication needs, so that the application can focus on its actual purpose. This could be done through reverse proxies specialized on authentication or similar concepts.
@toe Why would they reinvent the wheel with OIDC (of SAML)? It's fully standardised and has the advantage to be secure end2end instead of being terminated on a middle station (e.g. the proxy).
@sheogorath Just consider that your objective were to build a small point solution to solve a very specific problem for your organization. The application logic itself could probably be written by a junior developer within a couple of days.
But would you task that same junior developer with fully understanding and implementing OIDC+SAML?
And even if your answer were 'yes', would you decide the same if the project had a hard deadline?
@sheogorath Instead of a reverse proxy, as mentioned as an example above: a solid, well-written and well-vetted library would also be an option -- but this would be language specific
@toe I mean, it probably depends on the language, but to my knowledge pretty much any popular authentication framework already supports SSO. Therefore, I think I would risk it, to task the junior with "add and configure this framework library" rather than tasking them with "setup a reverse proxy for authentication".
But maybe we have very different languages and juniors in mind :D
@staticnoisexyz privacy risks originate from the choice of IDP. The IDP might be run by the same entity as the same as the application. So from a privacy perspective it makes nothing worse necessarily.
Much more it allows more granular access to user profile attributes, if the IDP supports it.
This is my personal microblog. It's filled with my fun, joy and silliness.