How single sign-on creates a dangerous false sense of security

This article is part of our Opinions section.

Identity is the new frontline in the battle against cyber threats. For years, single sign-on (SSO) has been a useful ally in this struggle, enabling organisations to mitigate the risk of password fatigue and shadow IT while streamlining the user login experience. But things are changing. Increasingly, compromised SSO credentials are finding their way onto the cybercrime underground. And threat groups are targeting identity providers (IdPs) themselves.

With SSO logins to hand, threat actors could do a tremendous amount of damage. So what’s the answer? It’s time for security teams to build multi-layered defences, in order to mitigate the impact of a potential IdP breach.

The problem with SSO

As organisations embrace cloud computing and applications and logins proliferate, SSO has become an increasingly popular tool to simplify and enhance identity and access management (IAM). But by centralising the point of authentication in this way, the system also paints a large target on the back of the IdP. And threat actors have increasingly shown themselves ready, willing and able to single out these organisations.

There are two scenarios. The first involves hackers targeting a single IdP instance via leaked credentials, social engineering, insider bribes and/or other tactics. In this case a specific customer will be impacted. The second, less common scenario is when attackers manage to exploit a vulnerability or misconfiguration to access the entire IdP — which can ultimately end up impacting all customers of the relevant identity solution.

Depending on the level of compromise, threat actors could steal application data, spy on users, downgrade application security and even create new privileged users and credentials.

Related reading: Why Identity & Access Management (IAM) must be your primary security layer

Never assume

In this context, every SSO provider becomes a potentially attractive target for threat actors. Customers that choose to have blind faith in the resilience of their IdP’s security posture could be in for a nasty surprise – as evidenced by a major threat campaign against Okta last year. Even as far back as 2022, research revealed that a quarter of the S&P 500 and half of the top 20 most valuable public US companies had at least one SSO credential for sale on the dark web. Hundreds became available for sale in just a two-month period.

The challenge is that threat actors have many ways to compromise the organizations that guard these keys to the kingdom. Social engineering may include voice phishing, a favourite tactic of the Scattered Spider group responsible for big-name extortion/ransomware attacks on MGM Entertainment and Caesars Entertainment. In the case of the former, the threat actors are said to have simply found an employee’s information on LinkedIn and impersonated them in a password-reset call with the IT helpdesk.

Nor is multifactor authentication (MFA) the key it once was to mitigating identity threats. Session hijacking can help threat actors bypass MFA, as can prompt bombing. The latter occurs when hackers use a victim’s username and password to attempt repeated logins, which trigger an MFA prompt for the legitimate user. After repeated attempts, an exhausted user may be tempted to simply accept the suspect login request to make the spam stop. It’s apparently been used by the infamous Lapsus$ threat group as well as the SolarWinds hackers.

Then there are brute-force attacks like credential stuffing and password spraying, that use automated software to try username/login combos in large numbers concurrently across multiple sites. Okta warned in March of threat actors launching credential stuffing attacks against the cross-origin authentication feature in its Customer Identity Cloud (CIC).

Building defence in depth

Yet if no SSO provider can be trusted, what can customers do to mitigate the threat of their highly privileged credentials falling into the wrong hands? Adding extra layers of security between the IdP and the relevant applications and services is a good place to start.

This “Infrastructure Defence-in-Depth” (IDiD) approach should at least include per-session phishing-resistant MFA, which requires new MFA checks when users start a new session. This will help to mitigate the risk of an attacker bypassing or controlling MFA in the IdP. It should also be mandatory for users to enrol a phishing-resistant MFA device when they create an account, to prevent weak access patterns. Requiring additional MFA verification for admin actions in a target application would also be useful, by mitigating the exploitation of compromised admins and blocking a lot of lateral movement.

Another simple but effective “layer” would be one enabling users to request access to a resource or role, enforcing the principle of least privilege and leaving an attacker with no permanent admins to target. Consider also dual authorization, which means two team members would need to authorize a privileged role—making life much harder for social engineers. Web authentication (WebAuthn)-based physical hardware/biometrics are another useful layer for second-factor checks when logging in to the defence-in-depth provider, as well as individual SSH nodes or Kubernetes clusters. And consider a device trust solution to complement the establishment of user identities and enforced roles.

Taken together, these multiple layers of defence will help to stop the bad guys in their tracks, even if they’ve compromised an IdP or SSO provider—by preventing them from pivoting from one breach to even more sensitive data. As threat groups increasingly turn their attention to these centralized providers, customers will need to be more proactive in managing identity risk.