Question

I am going to use the following scheme for implementing SSO –

Initial login –

1. Whenever a user loads a client app, he is redirected to the SSO login page.
2. Once the user logs in, an encrypted cookie token is set on the client and the value is also stored in the session.

Accessing another app –

1. When the user load another client app, he is redirected again to the SSO login page.
2. The SSO module first checks if the encrypted cookie exists and then compares the value with the value in the session.
3. If both of these match, it redirects the user back as authenticated.
4. Or else it asks the user to enter username / password.

Are there any security vulnerabilities with this scheme?

Thanks,
Murtaza

Answer 1

The design seems fairly standard for an SSO scheme. Of course, even if the concept is secure, vulnerabilities can arise in the implementation of the scheme. For instance, a secure implementation would need to guard against compromise of the SSO authentication cookies and vulnerabilities in the identity assertion to the relying system. Additionally, vulnerabilities in the authentication mechanism itself (such as weak passwords) could be amplified in an SSO environment where a single credential can be used to authenticate to multiple applications.

The use of both the encrypted cookie and session to identify the end user to the relying applications may be redundant, and may not be effective if the motivation is to defend against session hijacking attacks. If a HTTP request that includes these cookies is ever sent in cleartext, both the session ID and encrypted cookie cyphertext would be sent in the clear, potentially opening a spoofing vulnerability. (Of course, the cookie cleartext would not be sent, but an attacker would only need the cookie’s cyphertext content.) To mitigate this threat, the session cookie should be set as secure and the SSO login page accessible only through SSL.

If the motivation for an encrypted cookie is to allow the credential to be saved past the session lifetime, then care is needed to use appropriate cryptographic practices (e.g., key management and use of standard encryption algorithms). Of course, the cookie should be marked as secure to ensure (for practical purposes) that it is not sent in cleartext. Other countermeasures such as updating the cookie after each assertion to prevent duplication, and limiting the lifetime (e.g., requiring reauthentication every x days) may be warranted.

The scheme also requires that the verifier make an identity assertion to the RP after successfully authenticating the end user. There are several standard protocols for this, such as OAuth and OpenID.

Finally, the user should have recourse to terminate the SSO session to prevent unauthorized access when the user leaves the session.

Of course, the assurance requirements of the relying systems needs to be considered — what is the risk (in terms of likelihood and impact) if the SSO system is compromised? As the risk increases, so too does the cost-effectiveness of strategic and operational countermeasures (e.g., risk and vulnerability assessments) to defend against compromise.