Security Vulnerabilities of SSOs

Single Sign-On solutions, or SSOs, have become increasingly popular as a method for users to log into their favorite applications or platforms due to the convenience they afford. They spare users the arduous task of memorizing countless passwords for the growing number of applications available to them, as well as mitigate the security risk of users using the same password for all of their accounts. However, SSOs are not impervious to attack, and ignoring their vulnerabilities may impact their ability to continue to challenge other login solutions.

Certain technologies used by SSOs, such as SAML, have seen increased exploitation, rendering any SSO that implements it potentially insecure. Issues like this only compound as technologies age and developers don’t upgrade to newer, more improved variants. According to this article written by Rob Lemos for TechBeacon, researchers found that 1,660 of the 20,000 most popular sites utilized Facebook’s SSO, and 20% of those sites have at least one vulnerability researchers could test for. This has primarily been attributed to the use of outdated software and technology that still contains unpatched security flaws.

According to this article written by Jem Jensen for NETSPI, SSOs are a very valuable target for attackers due to their centralized nature, as they are one entity handling a large amount of critical information, such as passwords and usernames, for several other applications that are otherwise unrelated to one another. Because of this, if a connection or a database utilized by an SSO is compromised by attackers, they can gain a considerable amount of data related to multiple different applications. This has sparked some debate that SSOs introduce a single point of failure due to this highly centralized nature. If the SSO experiences a data breach or loss of availability, so do the clients that implement the SSO.

However, there are also some vulnerabilities with SSOs that aren’t technical and are just inherent risks that generally need to be accepted. One such example is the misuse of login credentials by users. If a user accidentally discloses their password to an attacker, the attacker doesn’t just have access to just one of their accounts, they have access to every account that utilizes that particular SSO solution. This is somewhat related to the idea that SSOs pose a risk of being a single point of failure, though the counter-argument is that SSOs can provide more security if they enforce proper password etiquette.

SSOs can make following the principle of least privilege more difficult as well. This principle dictates that users should only have access to the minimum amount of privileges, tools, and information required to complete the tasks assigned to their specific role. This is generally accomplished by having users sign in with another set of credentials, such as when logging into an admin account. However, SSOs inherently try to replace as many passwords as possible. For example, if implemented improperly within an organization, a user will log in with an SSO and automatically gain elevated privileges they don’t need, as the SSO will log them in on every application within the organization, violating the principle of least privilege.

In the scope of  technical vulnerabilities, there are several methods attackers may use to compromise an SSO infrastructure. A well known method, one that is generally used to steal user credentials as the user surfs the web, is referred to as ‘sniffing’. This exploit occurs when an attacker illicitly taps into a connection between a host and a client and intercepts information transmitted between the two. There are a variety of ways to do this, and the most common forms of mitigation against this type of attack is through authentication and encryption. Authentication, when configured properly, ensures the integrity of information transmitted between a client and a host, meaning it can be verified that it hasn’t been modified in transit. Encryption encodes the information so that it isn’t transmitted in easily readable plaintext. If outdated protocols are used, or no encryption or authentication is implemented at all, data-in-transit is generally considered vulnerable.

Most SSOs do implement these measures, but if they aren’t configured properly, they can still be exploited fairly easily, particularly if it is a severe and widely-known vulnerability. As an example, we will return to the case of SAML vulnerabilities. SAML messages are replies to authentication requests sent from the user to the identity provider, which then passes a SAML message back through the user’s browser to the service provider. This is done due to the fact that SSOs move the authentication functions to an external entity instead of being performed by the application the user is requesting access to.

There is a window of opportunity for exploitation as the SAML message passes through the users browser in which they can tamper with the message. The user can make adjustments to the authentication request, such as changing the expiration date to make the request valid beyond the point it was issued or changing the user ID to that of another user, potentially an admin. These attacks are often exacerbated by configuration flaws such as invalid signatures that aren’t issued by a legitimate CA (Certification Authority), or accepting SAML messages from other applications. To mitigate this threat as much as possible, the application must be properly configured during development, avoiding the aforementioned flaws.

This vulnerability is due to the fact SSOs are inherently a third-party entity that is handling login functions between a client and an application. The middleman in this particular attack is a malicious user who wishes to exploit an application that implements an SSO, leveraging the fact the authentication process must pass through their browser during the transaction, also capitalizing on SAML messages being designed to be easily decoded for the sake of speed.

Mitigating vulnerabilities like this is generally a trade-off between productivity and security. Both factors need to be considered, and you will need to decide on which is a higher priority for your organization. For example, requiring two-factor authentication may greatly enhance security, but it can inconvenience customers. 

Other forms of mitigations do exist, however. Authentication protocols are essential as they ensure that a connection or data-in-transit hasn’t been tampered with or otherwise compromised, so when choosing or implementing an SSO, it is incredibly important to select one that uses a modern authentication protocol such as OAuth 2.0. Faulty or compromised protocols only increase risks of tampering and sniffing attacks against data. In order to enforce the principle of least privilege, there should be a limit on what kinds of applications an SSO can be used to access, ensuring that it will not give users privileges they don’t need. SSOs can be considered a single point of failure if they do not implement a decent password policy, so frequent password changes and other security configurations should be implemented as well, depending on the amount of security deemed necessary by the organization implementing them.

If databases are used to store user credentials, SSO companies once again need to follow secure database guidelines, for example using secure SHA-2 hashing to store passwords in lieu of outdated and compromised MD5 hashing algorithms. As mentioned before, SSOs are considered high-value targets due to their highly centralized nature, so the security of data-at-rest is as critical as data-in-transit.

These vulnerabilities are a major concern for anyone developing or using an SSO solution, and one example of a startup that has implemented a variety of innovative mitigations is humanID. humanID’s infrastructure utilizes users’ SIM cards in their mobile devices to generate a unique ID, mitigating security risks posed by user-managed credentials. This ID is irreversibly hashed before being transmitted, making any sort of attack, whether it involves tampering or sniffing, incredibly difficult even if it is intercepted. This ID is not stored by humanID for any extended period of time, meaning that attackers have little opportunity to steal an ID number while the data is at rest.

SSOs offer a plethora of security benefits over traditional login methods, and in the case of many applications may serve as a better option. However, they aren’t without their vulnerabilities, some posing risks that will have to be accepted, while others can be avoided with proper mitigations. When choosing an SSO for your organization, it’s important to weigh your most critical objectives, and selecting a solution that adequately satisfies those requirements. If you’re searching for an SSO that offers security, privacy, and convenience, humanID is the right choice for you.