Follow

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!

@alcinnz @sheogorath I know what password managers are, I know what pubkey auth is and I know what SSO protocols are.

But what is a passwordmanager-backed pubkey authentication? And what is it supposed to solve? Protection of private keys?

@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!

@alcinnz @toe Why synchronise (probably) long-term cryptographic keys around, when you could just have (local) SSO providers the same way you have password managers?

Password managers are basically bad implemented SSO.

@sheogorath @toe Well, as long as I'm permitted to use local SSO operators...

@alcinnz @sheogorath I consider a single device limitation for private keys to be very desirable. Even better if they cannot be copied at all (think smartcard, FIDO2 and similar devices)

@toe @sheogorath And you can still have that!

But that limitation isn't always appropriate... And yes, it'd be great to support smartcards in those cases!

@toe @sheogorath You can have cryptokeys just like today which aren't sync'd, & cryptokeys which are. Treated entirely seperately! Such that I'm not changing anything for you.

Just don't mind me as I encourage people to install passwordmanagers in a mission to transition smoothly beyond passwords!

@alcinnz @sheogorath Don't get me wrong. I like password managers and encourage their use.

It is just that they are a mitigation and not a fix to the underlying problem.

@sheogorath why? to depend on some centralized proprietary crap that may spy on users?

@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".

@sheogorath account recovery existed for decades, and trivially worked without all this spyware. and if the implementation is opensource and it's set up on your server what's the difference with any other realization? absolutely no difference. moreover, open source code that works with security, must be thoroughtly checked and this is even more work than realization of standsard authorization schemes that worked for ages.

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

@sheogorath usually, there're libraries for this. normal open source libraries. but I would never consider using any authorization that relies on third-party servers and/or resources.

@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: owasp.org/Top10/A07_2021-Ident

Have one specialised application deployed that takes care of all of it, everything else, just use standard SSO protocols, done.

@sheogorath this is only in case if a developer is a monkey that does not a shit about what he's doing. but the developers that write such software know what they do. \
CWEs don't exist in vacuum. they are referring to certain use cases. and use cases are different. not everything listed is a "vulnerability", it depends on the case.
and imposing everybody to use one realization is a single point of failure and universal attack mechanisms. this is not acceptable for open source and leads to proprietary-like problems and issues.
and SSO implies storing of user credentials on some unknown third-party server which is a general security hole number one.

@iron_bug

> 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?

@sheogorath and I really have a big question to any resources that use passwords. ther're RSA keys and this is more secure, much more safe and easy to use. but by some weird reasons instead of user certificates and RSA keys people use passwords and stupid 2FA.
@sheogorath and yes, if user wants, he can set a password for his RSA key too.

@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?

@sheogorath nope. client certificate is an authorization. it's enough on its own. it's often used in companies resouces access and works well and needs no SSO.
@sheogorath client certificate is just client side RSA key that is used for accessing some resouces. it's just also signed with the issuer's CA key. it has the same security level as any RSA authentication. and it's much more secure than any passwords, non mentioning referring to any third-side servers for authorization which is a security problem per se: the channel to the third-side resources may be compromised in multiple ways, especially on user side.

@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 it's common encryption. you may set up your own CA and add the root certificate to trusted list, if you want to get rid of third-party public root CAs. but nobody does this, because breaking of root CA servers makes the significant parts of the Internet disabled, factually. this happens too rarely.
and without network connection there's no meaning in talking about user authorization. locally all Linux systems have safe and long ago checked solutions for authorizing unsers. nobody needs some SSO. especially without network.

@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

@sheogorath ok from a security standpoint, but does not take privacy risks into consideration

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

Sign in to participate in the conversation
Sheogorath's Microblog

This is my personal microblog. It's filled with my fun, joy and silliness.