White Papers Problems with Traditional E-SSO
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Problems with Traditional E-SSO


This document lays out what works and, more importantly, what doesn't work well with traditional approaches to enterprise single sign-on. It goes on to describe an alternate approach to reducing the frequency of sign-on prompts presented to users, that does not have any of the problems described here.


Enterprise Single Sign-on

This document is primarily concerned with Enterprise Single Sign-on (E-SSO) applications:

Enterprise single sign-on (E-SSO) systems are designed to minimize the number of times that a user must type their ID and password to sign into multiple applications.

Most enterprise single sign-on systems work as follows:

E-SSO software acts as a surrogate for the user: storing, retrieving and "typing in" the user ID and password on behalf of the user. The user continues to have multiple ID/password pairs, but does not have to type them manually and may not know what they are.

With an E-SSO system, users sign into their workstation with either one or two login ID / password pairs: One set of credentials if the E-SSO captures the user's password from the initial workstation login screen, or two ID/password pairs if the user must first log into the workstation (e.g., Windows login) and subsequently into the E-SSO client software.

Some E-SSO systems support use of authentication technologies other than passwords to sign into the workstation and retrieve the user's application passwords. This may include smart cards, authentication tokens or biometric samples.

Application login IDs and passwords may be stored on a smart card, rather than on the user's workstation or on the network.

Web Single Sign-on

This document does not pertain to Web Single Sign-on (WebSSO) applications, but they are described here for completeness:

A Web access management (WebAM) / Web single sign-on (WebSSO) system is middleware used to manage authentication and authorization of users accessing one or more web-enabled applications. Is supports single sign-on across systems and applications which do not natively support federation.

A WebSSO system intercepts initial contact by the user's web browser to a web application and either verifies that the user had already been authenticated (typically tracking authentication state in a cookie) or else redirects the user to an authentication page, where the user may use a password, token, PKI certificate or other method to authenticate himself.

Once a user is authenticated, the WebAM component of the system controls the user's access to application functions and data. This is done either by filtering what content the user can access (e.g., URL filtering) and by exposing an API that the application can use to make run-time decisions about whether to display certain forms, fields or data elements to the user.

WebSSO / WebAM products typically use an LDAP directory as a back-end repository, to identify all users. They often come tightly integrated with an "identity management and access governance" application, which enables delegated and in some cases self-service administration of the contents of that single directory.

Federation is almost always preferable to WebSSO. Commonly available WebSSO / WebAM products are appropriate to both Intranet (thousands of high-value, high-complexity, low transaction-volume users) and Extranet (millions of low-value, low-complexity, high transaction volume) use.

WebSSO / WebAM products are available from major platform vendors. Most of these were acquired from smaller, specialty software makers:

  1. CA (formerly Netegrity) SiteMinder.
  2. Oracle (formerly Oblix) COREid.
  3. IBM Tivoli Access Manager (TAM).
  4. RSA (formerly Securant) ClearTrust.

It should be noted that while the identity management and access governance components of these WebSSO / WebAM products are generally robust solutions for managing a single (LDAP) directory, they are unsuitable to managing complex users with multiple accounts on multiple systems, as they have no concept of multiple target systems or users with unique combinations of accounts.

Password Synchronization

Vendors that make traditional E-SSO products like to suggest that password synchronization is somehow bad (compromise one password and all are compromised).

An alternate approach to single sign-on, described later in this document, is actually based on password synchronization.

For these two reasons, it makes sense to define password synchronization here:

Password synchronization is any process or technology that helps users to maintain a single password, subject to a single security policy, across multiple systems.

Password synchronization is an effective mechanism for addressing password management problems on an enterprise network:

There are two ways to implement password synchronization:

Operational Problems with Traditional E-SSO

The core element in every traditional E-SSO product is the concept of a credential database. This may be encoded in different ways and stored on various media but fundamentally it is a set of login ID / password pairs that the E-SSO application will type on behalf of the user when each application prompts for login verification. This data must be available for every user.

(1) Previous approaches to enterprise single sign-on systems had problems, all related to the password database where application login IDs and passwords are kept:

Some E-SSO vendors try to turn some subset of these problems into competitive advantages, or as a justification for cross-selling other products:

  1. Some vendors create a mechanism for users to display their own plaintext passwords, when accessing applications from non-traditional devices. This is, of course, insecure.

  2. Citrix uses the remote-availability problem to encourage customers to migrate their users to Citrix Presentation Manager. If users access every application by remote control, and the terminal services servers are equipped with SSO, then the problem goes away (and Citrix sells more server licenses).

  3. Most vendors offer some back door, to bypass the credential encryption system with some privileged credential and so to address the problem of expensive password resets. This can create security weaknesses and/or administration headaches.

These operational problems are serious. It is Hitachi ID Systems's opinion that these problems prevent most large enterprises from completing large-scale E-SSO deployments. Instead, pilots and department-scale deployments, which work reasonably well, hit these roadblocks when trying to scale up, and project scope is subsequently curtailed.

Is E-SSO More Secure than Password Synchronization?

Many E-SSO vendors claim that E-SSO is more secure than password synchronization. They reason as follows:

  1. If passwords are synchronized, then:
    1. A compromise of one security database will compromise all systems.
    2. An intruder can make more incorrect password guesses before triggering a lockout, since he can distribute guesses across multiple systems.

  2. In contrast, in an E-SSO system, every password is different, so these "vulnerabilities" disappear.

  3. Using an E-SSO system together with a two-factor authentication system eliminates passwords altogether. This sounds more secure.

These arguments are very weak, however:

  1. Few, if any, modern password databases are vulnerable to total compromise:
    1. Most systems do not make password hashes available to a would-be attacker.
    2. Password guessing attacks depend on weak passwords, which are easy to prevent using either built-in policies or an external password management system.
    3. Most systems do implement an intruder lockout system, which prevent brute-force attack against their public authentication mechanism.

    As a result, a compromise of any one security database is quite unlikely. If such a compromise were as easy as claimed, then every corporate network would be under constant and successful attack, which is clearly not the case.

  2. The argument regarding a higher number of failed authentication attempts before an intruder lockout is triggered is accurate, but largely irrelevant. If a user has a strong password (this is easy to achieve -- see above), does it really matter if an intruder can try 3, 10 or 100 guesses before being locked out?

    Current security best practices generally recommend setting the intruder lockout counter high (on the order of 50 -- 100 failed attempts) anyways. A low count is no substitute for strong passwords and if passwords are strong, there is no harm in setting the counter high, since the password will not be guessed in anything short of billions of guesses.

  3. It's true -- with either password synchronization or E-SSO, if an intruder compromises one password, he has compromised all passwords for the affected user. In the password synchronization case, an intruder who compromised any of a given user's (victim's) passwords has compromised them all, since they are the same. In the E-SSO case, an intruder who has compromised the victim's primary password has compromised them all: the others can be decrypted using the primary password and the E-SSO product will obligingly log the intruder into those systems anyways.

    In other words, the only difference between password synchronization and E-SSO in relation to the single password argument is which password must be compromised before all are compromised -- the primary password or any of them. This is not much of an advantage for E-SSO.

  4. Using stronger authentication technologies sounds good, but the application passwords are still there -- still encrypted using a primary key and still used to log into each application. Moreover, when deploying stronger primary authentication, the method used to generate or acquire the key which decrypts all the user's application passwords is often obscure and in some cases is easily compromised. In other words, strong primary authentication is often accompanied by weak encryption of sensitive application passwords.

Hitachi ID Login Manager: A New Approach to E-SSO

Having debunked the security argument, the remaining advantage of E-SSO systems is that they improve the user experience, by reducing the number of times that a user, in a given day, must type his ID and password.

The problem with E-SSO is basically the credential database -- it is expensive to acquire and maintain, is an attractive target for attackers and prevents users from accessing applications from devices that are not equipped with the E-SSO client software.

Login Manager automatically fills in application login IDs and passwords on behalf of users, streamlining the application sign-on process for users.

Login Manager works as follows:

The net impact of Login Manager is that login prompts for applications with well-known IDs and passwords that authenticate to AD or are synchronized with AD are automatically filled in. This is done without:

Login Manager is installed as a simple, self-contained MSI package. It does not require a schema extension to Active Directory.

The reduced sign-on process used by Login Manager has several advantages over traditional E-SSO techniques:

These advantages significantly reduce the cost and risk associated with deploying and managing Login Manager.

In order to achieve its benefits of low cost and high availability, Login Manager makes three important assumptions: