Sign in as anyone: Bypassing SAML SSO authentication with parser differentials

Is SSO salvageable at all? It seems like the idea of just logging into different accounts is fine.

Also just the idea of connecting your accounts together such that you can get megacompromised is foundationally riskier

One can use OIDC instead of SAML for SSO.

SAML is not the only standard for SSO. Before SAML we had Kerberos and nowadays you can use Open ID Connect. Other standards can have their own gotcha, but SAML is uniquely horrendous.

When we get vulnerabilities in the SSO protocol (SAML or otherwise) these vulnerabilities generally only affect some of the clients (identity consumers) who have implemented the protocol incorrectly or are using a feature that the provider has implemented incorrectly. Vulnerabilities that break the entire provider are less common.

When comparing this situation to having multiple different accounts, I can't see how SSO is less secure. Sure, when you have breach that affects the entire identity provider the damage is high, but the risk of having a breach (any breach!) is lower, since implementations are fewer, more consolidated and usually developed by people with better expertise.

OIDC is better than SAML, but that isn't a high bar. And OIDC has its own problems.

OIDC's problems are nothing like those of SAML.

The biggest problem with having separate accounts for everything is that a lot of the users will make their own "wish it were SSO" by setting their passwords in the systems to the same value. Then, when the weakest system is exploited, the attacker gets credentials that are valid across the organization. Yes, they should be using a password manager with unique, random passwords for each system, but realistically a good chunk of larger organizations' staff are not going to do that.

Some other headaches:

Having decentralised authentication means that onboarding and offboarding need to have a bunch of tedious manual steps, or custom automation.

Whoever does user support for the organization has to be trained to reset passwords/unlock accounts in a hodgepodge of systems.

Any security controls the organization wants to implement need to be reimplemented or approximated in a bunch of different systems. E.g. if there are regulatory requirements for account lockouts, time between explicit reauthentication, etc.

It becomes much more critical to collect the authentication logs/event data for all of those systems, and harmonize its formatting with everything else so that the security ops team isn't maintaining separate monitoring/alerting rules for every system.

For large-scale systems, there are also at least theoretically performance advantages to the kind of signed ticket approach that SSO mechanisms tend to use, versus having to do database lookups of session IDs or verify a password. It's possible to do that without SSO, but if you're going to the trouble of implementing that kind of mechanism, you're most of the way to having SSO anyway, and might as well just finish the job IMO.

Often password rules make slight variations of the passwords so that the damage is limited.

Furthermore, attackers don't try all accounts since they don't know which ones exist (unless they have email access).

"If there are regulatory requirements for account lockouts"

Then the vendor can impmenent those? The need for control might be a source for greater risk.

> Having decentralised authentication means that onboarding and offboarding need to have a bunch of tedious manual steps, or custom automation.

Furthermore, SAML SSO alone does not save you from worrying about this, ideally you'd also implement SCIM, to have actually automated + real-time identity updates, which is yet another protocol separate from SAML.