What are the disadvantages of single sign-on authentication?

Question

We were discussing to implement single on in our web application,right now after analyzing we came to know that the following were the advantages of single sign on authentication. In the words of Shwetha on the Cymfony System Testing blog:

Advantages

• Users select stronger passwords, since the need for multiple passwords and change synchronization is avoided.
• Inactivity timeout and attempt thresholds are applied uniformly closer to user points of entry.
• It improves the effectiveness/timeliness of disabling all network/computer accounts for terminated users.
• It improves an administrator's ability to manage users and user configurations to all associated systems.
• It reduces administrative overhead in resetting forgotten passwords over multiple platforms and applications.
• It provides users with the convenience of having to remember only a single set of credentials.
• This also improves security as users find it easier to remember their credentials and do not have to write them down, allowing for a more efficient user logon process.
• It reduces the time taken by users to log into multiple applications and platforms.

What disadvantages exist when implementing single sign on technology?

Answer 1

• Single point of failure

• Single high-value target (attracts more attackers)

• Necessary information disclosure between trusting site and SSO authority

• Side channel attack against authentication step (theoretically; implementation dependent)

• Lack of control over your user list

• Yet another interface to maintain (added complexity)

• You may never know how secure your system is or if there is a breach

• Added cost

These are all off the top of my head. I imagine someone has compiled a canonical list somewhere.

Answer 2

This started off as a comment to Tyler's answer but running out of space.

Yes, if you implement it badly, then there will be bugs which can be exploited - but there are only 2 pinch points where SSO is different from seperated systems in this regard - when transitioning from the SSO site into the application site, and when terminating an SSO session (and hence sessions on the trusting applications).

Single point of failure

Only if it's badly implemented.

Necessary information disclosure between trusting site and SSO authority

How are you exposing more information to the trusting site? Indeed, there is much less opportunity for exploiting the application when it does not handle the authentication itself.

Lack of control over your user list

How? If you control both your applications and the SSO then why do you have less control?

Yet another interface to maintain

Defining interfaces and appropriate isolation between system components is good practice. SSO merely forces you to apply this practice. I think that's a benefit. Indeed maintaining a single implementation of the code for authentication rather than multiple ones should reduce complexity and cost.

You may never know how secure your system is or if there is a breach

How is this different from standalone systems?

Added cost

As per point regarding interface - it shouldn't add code complexity, nor does it require additional hardware. The only added cost I can think of is the need for an additional SSL cert - which is hardly that much.

If you are handing your security mechanisms to an opaque 3rd party then most of the points are valid - but not if you are implementing the system yourself.

There is a slight performance overhead with redirects for users only accessing a single application - but not huge.

Answer 3

You don't say if the scope for SSO is intranet or internet. If it includes internet then I've got a lot of love for SAML 2.0 compliant sites, however there are some disadvantages of SAML2.0 and SaaS sites:

1. A lot of SaaS vendors (service providers) do not support all the SAML 2.0 assertions, e.g. joiners/movers/leavers assertions so you don't get all the benefits of SAML2
2. Agreeing the SAML2 assertions with a SaaS vendor can be quite hard work to begin with.
3. if the SaaS site requires federated SSO for, say staff users, and then continued access when the staff leave then you get into some horrible dual mode authentication that weakens the overall solution. i had this with a payslip system where staff are meant to continue to have access once they have left the company. i.e. where the IdP (identity provider) is the internal staff directory.
4. SAML2 compliant products (for your side of the firewall) are expensive and dominated by one company (so difficult to negotiate price)

other than that - if you can get all SaaS sites working for your org with SAML, linked to your own identity store then you will have knocked out a huge risk, especially since users choose the same password for all corporate logins.

The worst thing you can do (mentioned above) is cook your own SSO scheme.

Answer 4

First, let us start with the disadvantages of all SSO solutions:

• Cost of migration (time and resources).
• Cost of additional plugins and subscriptions that make it possible to integrate your applications (Jira, Slack, WordPress, etc.) with your SSO, as it is usually not available in the free version or lowest subscription, and sometimes it requires installation of a plugin. Some applications might turn out to be extremely hard or impossible to integrate, so it is better to research this earlier.
• If you use any applications developed by your company, you will have to write the integration yourself. Remember that a badly written integration can also result in critical vulnerabilities and lead to unauthorized access to the application.
• It always requires proper knowledge (the simplest way to introduce vulnerabilities is via improper configuration).
• If an attacker gains access to a victim's account, they have access to everything, usually including a VPN. However, it can be mitigated with proper security measures (password policy, enforced MFA, a separation between normal user accounts and administrator accounts, conditional access like IP allowlisting).
• SSO is not applicable everywhere – it is mostly used with web, mobile, and desktop applications. Your IAM solution should also include a way to connect to server infrastructure, Wi-Fi networks, etc.

You should also note that there are multiple options regarding the SSO, and each of them comes with its own set of advantages and disadvantages.

1. On-premises SSO, managed by your organization, could be either an open-source product (e.g., Keycloak) or a closed-source one (e.g., AD FS). This option has the following disadvantages:

• Must be managed by your own team – requires maintenance and regular security updates.
• Can be a Single Point of Failure – if SSO stops working, users cannot log in anywhere. It is mitigated via proper redundancy and the creation of a backup authentication channel for administrators. On the other hand, SaaS SSO usually guarantees availability.
• You must set up your own logging and monitoring mechanisms to ensure the security of your SSO – if you use quality SaaS, they usually have constant monitoring.

Moreover, if your SSO is available only on your intranet (via VPN or in the office), it has the following disadvantages:

• Requires the employees to connect to the intranet to have access to the SSO – which is not exactly a downside but can be a challenge.

• It is not possible to set up OpenID Connect integration with an application that does not have access to the intranet (however, most SaaS offer SAML integration, which will be fine).

However, if available publicly, the attack surface is obviously wider and might require more configuration to make sure that the admin interface is secure (e.g., restricted to VPN).

2. The second option is SaaS SSO, managed by a third party (e.g., Azure AD, Okta).

• You must trust a third party, so it is important to choose an Identity Provider with a good reputation.

3. The worst option is usually developing your own Identity Provider.

It is great that you want to make sure that you consider all disadvantages before proceeding with the migration. Afterall, it all boils down to the threat analysis and implementing proper mitigations.

Answer 5

SSO’s challenges Extra-strong passwords must be enforced. If an SSO account is cracked, others under the same authentication can also be endangered. When SSO is down, access to all connected sites is stopped. This is a big reason to exercise great care in choosing an SSO system. It must be exceptionally reliable and plans should be in place for dealing with breakdowns. What’s more, when your identity provider goes down, your SSO does too. The provider’s vulnerability to any kind of interruption becomes your vulnerability as well, and it is probably beyond your control. Once again, the choice of vendors is critical.

If a hacker breaches your identity provider user account, all your linked systems could be open to attack. This can be a classic single point of failure and should be headed off in the planning process. On the plus side, high-quality identity providers have top-notch security.

SSO can take longer than expected to set up. Each environment is different, so added steps in implementation can crop up. One example is the task linking the identity provider to the service provider.

SSO is risky for multi-user computers. What happens when one user is logged in and another needs to use the machine?

Reduced sign-on (RSO) may be needed to accommodate different levels of access. With RSO, additional authentication servers may be required.

SSO using social networking services can create conflict. This can be the case with workplaces that block social media sites and government connections where censorship is involved.

Some SSO-linked sites may give their user data to third-party entities. This is an area requiring careful attention.

[The Pros and Cons to Single Sign-On (SSO)] [1] (RenovoData, 2019)

I also found this link helpful, especially this section:

One misconception about using an SSO solution is that it weakens security. The argument rests on the premise that if a master password is stolen, all related accounts will be compromised.

In theory, this appears to be true, but with common-sense practices, SSO can actually reduce password theft. How?

Since users only need to remember one password for multiple applications, they’re more likely to create a stronger (harder to guess) passphrase, and less likely to write it down. These best practices reduce the risk of password theft.

As explained in the next section, a single sign-on strategy can also be combined with multi-factor authentication (MFA) for extra security.

[7 Benefits of Single Sign-On (SSO) and Why Your Business Needs It][2] (Gupta, 2020)

A simpler explanation can found here: [The Advantages and Disadvantages of Single-Sign-On (SSO) Technology (mini-whitepaper)][3]

[1]:RenovoData. (2019, January 17). The Pros and Cons to Single Sign-On (SSO): RenovoData - The Data Protection Blog. https://www.renovodata.com/blog/2019/01/17/single-sign-on

[2]: Gupta, D. (2020, May 13). 7 Benefits of Single Sign-On (SSO) and Why Your Business Needs It. Identity Blog. https://www.loginradius.com/blog/2019/11/benefits-single-sign-on-sso/

[3]: Gupta, D. (2020, May 13). 7 Benefits of Single Sign-On (SSO) and Why Your Business Needs It. Identity Blog. https://www.loginradius.com/blog/2019/11/benefits-single-sign-on-sso/