Understanding and Mitigating Single Sign-on Risk

With the average enterprise using almost 1,000 applications, it's no surprise that single sign-on (SSO) has become such a critical gatekeeper. It provides ease of access and can eliminate the sprawl of usernames and passwords that haunt users and frustrate administrators.

While SSO is useful, it's not without inherent risk. Since it uses a one-to-many architecture, if an identity is breached, an attacker instantly gains access to all of the resources that particular account holder is authorized to use. As we know, users will often select weak passwords and can easily fall prey to phishing attacks.

Another challenge is that not every system can use a single sign-on solution, leaving gaps in security. While most SSO technologies can support multiple cloud-based applications, homegrown and legacy applications require different approaches, like Microsoft Active Directory. This creates identity silos and creates massive complexity.

Meanwhile, passwords remain the weak link in any security implementation, including SSO, because they don't actually validate the identity of the user.

Mitigating SSO Risks

Multifactor authentication (MFA), which is supported by many SSO solutions, is usually layered on top of usernames and passwords, but there's no identity verification taking place other than something you know (mother's maiden name or such) and something you have, such as your cellphone. Combining MFA and identity verification will fill some of the gaps in SSO.

Adding identity verification works well for organizations that already scan employees' biometrics, drivers' licenses, or passports in the hiring process because they already have a proof of identity on file for comparison. Identity-proofing all employees before issuing credentials is a strong first step toward bringing SSO into the zero-trust world, which requires reauthentication when risk factors are elevated.

However, in order to implement zero-trust access, organizations must validate a user's identity and not just require an additional authentication factor. That's because if an attacker has compromised a user's identity, asking for reauthentication or a second form of authentication will not detect that the access request is being made by someone who is not actually the authorized user. Without this fundamental understanding of identity, any authentication method including SSO cannot be trusted.

Replacing passwords as the main method of identifying a user is the key first step in making SSO more secure, but several other techniques can build on that effort to make it even more secure and easy to use. Security analytics can be used to detect anomalies in user behavior patterns. For example, if a user has made a few failed attempts to log on or is connecting from an unusual device or location, the system could require a new secondary form of authentication.

It's also important to understand what digital assets are not covered by SSO. For example, custom-built and legacy applications don't not easily integrate with SSO. Therefore, an approach that marries identity verification with authentication provides the trust levels necessary to support both SSO and extend passwordless access to assets that are not covered by SSO.

If an SSO implementation is still based on passwords, it's extremely important to establish a secure password reset process. For example, using verified biometrics that use what's called liveness detection to make sure that a static image of the user is not being used to spoof the system. This type of capability can ensure the authorized account holder is present when resetting a password, and that the reset is not being performed by an attacker.

Clearly, SSO's one-to-many architecture is both a big advantage and a weakness. By supplementing SSO with identity verification and advanced MFA, it's possible to eliminate passwords in a safe and secure fashion.