Problems with Traditional E-SSO

Overcoming Operational Challenges with

Traditional Approaches to Enterprise Single Sign-On

Š 2014 Hitachi ID Systems, Inc. All rights reserved.

Contents 1 Introduction

1

2 Definitions

1

2.1

Enterprise Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

2.2

Web Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.3

Password Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

3 Operational Problems with Traditional E-SSO

3

4 Is E-SSO More Secure than Password Synchronization?

5

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

6

i

Overcoming Operational Challenges with Traditional E-SSO

1 Introduction 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.

2 Definitions 2.1 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 client software is installed on every user workstation.

• Users sign into their workstation, either as they did before or through a new user interface presented by the E-SSO client software.

• A local file, a network-attached database or a user directory stores each user’s ID and password, for each system and application to which that user has access.

• When a user launches an application on their workstation, the E-SSO client software automatically populates the ID and password fields in that application’s login screen with data from the aforementioned credential storage.

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.

© 2014 Hitachi ID Systems, Inc.. All rights reserved.

1

Overcoming Operational Challenges with Traditional E-SSO

2.2 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.

2.3 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

2

Overcoming Operational Challenges with Traditional E-SSO

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: • Users with synchronized passwords tend to remember their passwords.

• Simpler password management means that users make significantly fewer password-related calls to the help desk.

• Users with just one or two passwords are much less likely to write down their passwords.

There are two ways to implement password synchronization: • Transparent password synchronization, where native password changes, that already take place on a common system (example: Active Directory) are automatically propagated through the password management system to other systems and applications.

• Web-based password synchronization, where users are asked to change all of their passwords at once, using a web application, instead of continuing to use native tools to change passwords.

3 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.

Previous approaches to enterprise single sign-on systems had problems, all related to the password database where application login IDs and passwords are kept: • Remote Access and Mobile Devices: Over time, a traditional E-SSO system will respond to applications expiring passwords by choosing new, random password values, allowing the application to change passwords and storing the random password value for future reference.

With this process in place, over time users lose knowledge of their own passwords and become dependent on the E-SSO system to sign into their applications. This means that users cannot access their applications from devices that are not equipped with the E-SSO software, such as smart phones or even their home PCs. • Cost to Deploy: Building and maintaining a database of every login ID and every password on every application can be both costly and time consuming. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

3

Overcoming Operational Challenges with Traditional E-SSO

• Cost to Reset Passwords: Login IDs and passwords stored in a traditional E-SSO system are typically encrypted using a key derived from the user’s primary network password. When users forget their primary password, they lose this key and can no longer decrypt their application passwords. As a result, password problems may be less frequent with E-SSO, but resolving them is more complicated, time consuming and expensive.

• Security and Availability: In the event that the password database in a traditional E-SSO system is compromised, every user ID and every password would be exposed.

If the password database suffers an outage, every user would be locked out of every application.

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’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.

© 2014 Hitachi ID Systems, Inc.. All rights reserved.

4

Overcoming Operational Challenges with Traditional E-SSO

4 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: (a) A compromise of one security database will compromise all systems. (b) 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: (a) Most systems do not make password hashes available to a would-be attacker. (b) Password guessing attacks depend on weak passwords, which are easy to prevent using either built-in policies or an external password management system. (c) 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

5

Overcoming Operational Challenges with Traditional 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.

5 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.

Hitachi ID 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: • When users sign into their workstations, Login Manager acquires their network login ID and password from the Windows login process.

• Login Manager may (optionally) acquire additional login IDs (but not passwords) from the user’s Active Directory profile.

• Login Manager monitors the Windows desktop for newly launched applications: – It detects when the user types one of his known login IDs or his Windows password into an application dialog box, HTML form or mainframe terminal session. When this happens, the location of the matching input fields is stored on a local configuration file.

– Whenever Login Manager detects an application displaying a previously configured login screen, it automatically fills in the appropriate login ID and/or the current Windows password.

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: • Interfering with user access to applications from devices not equipped with the SSO software, such as their smart phones.

• Having to deploy a secure location in which to store application credentials.

• Writing scripts.

© 2014 Hitachi ID Systems, Inc.. All rights reserved.

6

Overcoming Operational Challenges with Traditional E-SSO

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: • There is no global directory or database with user credentials: – There is no target for a would-be attacker.

– There is no single point of failure which could cause a widespread disruption to users who wish to sign into applications.

– There is no need to enroll users by having them provide their passwords.

• There are no manually written scripts: – No manual configuration is required.

– No infrastructure is required to distribute script files to PCs. • Continued access to applications: – Users sometimes need to sign into application from devices other than their work PC. – Since passwords are synchronized and users know their own password, they can still sign in, even without the SSO software.

– In contrast, with other E-SSO products, users may not know their own application passwords.

This disrupts application access using a smart phone, home PC, Internet kiosk, etc.

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: • The set of login IDs associated with a given user is known.

It may either be a single ID (i.e., the user’s network login), or a short list.

Where users have different login IDs on different systems, Hitachi ID Password Manager can generate login ID aliases using a combination of automation and self-service enrollment and can write this data to the user’s profile in Active Directory or eDirectory. Login Manager can retrieve this list of login IDs at login time.

• Passwords are consolidated or synchronized.

Since Login Manager does not store a user’s passwords anywhere, it depends on a user’s application passwords being the same as the user’s primary network password.

• Users sign into their workstations with a password.

Since Login Manager acquires a user’s primary network password from the Windows login process, that process must itself use a password. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

7

Overcoming Operational Challenges with Traditional E-SSO

Combining Login Manager with other authentication technologies, such as smart cards or one time password tokens, may require extra integration effort, so that Login Manager can retrieve the user’s synchronized password from a different source.

500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com

www.Hitachi-ID.com

File: /pub/wp/documents/problems-with-traditional-sso/problems-with-traditional-sso Date: 2006-10-17