This document summarizes the problems users experience when managing too many passwords. It describes the various approaches available to organizations to reduce the password burden on users and to improve the security of their authentication systems.
Given this background information, this document goes on to describe the basic architecture of traditional enterprise single sign-on (E-SSO) systems. It describes their strengths, along with their security, usability and cost issues.
Finally, a new approach is presented, to deliver most of the same advantages of a traditional E-SSO system but without any of the traditional issues. The new approach replaces a database of stored passwords with a password synchronization process. This is the approach embedded in Hitachi ID Login Manager.
Users who must manage multiple passwords to corporate systems and applications have usability, security and cost problems.
Users have too many passwords. Each password may expire on a different schedule, be changed with a different user interface and be subject to different rules about password composition and reuse.
Some systems are able to force users to select hard-to-guess passwords, while others are not. Some systems require that users change their passwords periodically, while others cannot enforce expiration.
Users have trouble choosing hard-to-guess passwords.
Users have trouble remembering passwords, because they have too many of them or because they chose a new password at the end of the day or week, and didn't have an opportunity to use it a few times before going home.
These problems drive users to choose trivial passwords, to avoid changing their passwords and to write down their passwords. All of these behaviors can compromise network security.
When users do comply with policy and regularly change their passwords to new, hard-to-guess values, they tend to forget their passwords and must call the help desk.
Password and login problems are the top incident type at most IT help desks, frequently accounting for 25% or more of total call volume.
In addition to the above security and support cost problems, users simply don't like memorizing and typing passwords. Password management is a nuisance that contributes to a negative perception of IT service.
Despite all these problems, passwords will continue to be needed for years to come:
Since passwords are not going away and remain difficult for users to manage, solutions are needed to help users more effectively manage their passwords.
There are multiple approaches to reducing password problems for both end users and IT organizations. These approaches are complementary -- organizations can and most do deploy more than one:
Most organizations have deployed at least one enterprise-wide directory. This may be Active Directory (Microsoft), eDirectory (Novell) or another LDAP-based system (typically Sun or IBM).
Many applications can be configured to validate login IDs and passwords on the directory rather than locally in application-specific security databases. Doing this reduces administration burden on IT (fewer login accounts to provision and support) and on users (fewer login IDs and passwords to remember).
This strategy is attractive and should be pursued wherever possible. Its limits are primarily (a) applications that do not support authenticating users against an external directory and (b) organizational boundaries that do not permit an application in one domain to authenticate users using a directory in another domain.
In Windows/Active Directory networks, user workstations are assigned a Kerberos ticket when users sign in. The ticket is an encrypted file with assertions about the user's identity and security group memberships. The workstation can pass this ticket, avoiding the need for further authentication, to applications that have been configured with "Windows integrated authentication."
Similarly, one web site can be configured to trust another site, which has already authenticated a visiting user. The identity of the user, as claimed by one site, is passed to another site using federation protocols such as SAML, WS-Federation, Liberty Alliance and Shibboleth.
The approach of having one system authenticate a user and pass assertions about the user's identity is an attractive solution where it is technically feasible to implement the trust mechanism between applications and where the trust relationship is based on real trust between the organization that operates one system and the organization that operates another.
Applications which are accessed using a web browser are especially amenable to a strategy of replacing internal authentication with a shared directory infrastructure. A whole class of web single sign-on products (WebSSO) allows organizations to replace application-specific credentials with a shared directory.
WebSSO systems work by intercepting user attempts to access an application, checking whether the user has already been authenticated, possibly diverting the user to a shared login system and ultimately injecting user identity information into the web session. This may be done by adding agents on each web server or by placing a reverse web proxy server between users and web applications, which modifies the HTTP(S) data stream.
WebSSO systems are also attractive, and should be used where possible. Their limitation is their platform -- they do not work for terminal sessions, client/server applications and any other system whose communication protocol is other than HTTP(S).
Even after directory consolidation and web single sign-on have been deployed, there often remain multiple passwords per user. Users typically continue to have a login ID and password on the network (often Active Directory), e-mail system (often Exchange or Lotus Notes), ERP system (typically SAP R/3, PeopleSoft or Oracle eBusiness Suite), a mainframe system (RACF, ACF2 or TopSecret) and possibly a variety of custom or vertical applications, which may have a Unix or database back end. Increasingly, users also have logins on externally hosted applications -- Salesforce.com, Google Applications, etc.
An effective strategy to approaching the remaining complexity is to install a system that captures password changes on one system and forwards new passwords to other systems. This way, users still technically have multiple passwords, but they happen to be set to the same value at all times, eliminating the need to remember multiple passwords, change them in multiple places, etc. This approach is password synchronization.
Password synchronization is attractive because it is relatively inexpensive to acquire and deploy. There is no need for client software, user training, etc.
The limitations of password synchronization are (a) that it requires explicit integrations with each password database and (b) that users still have to type their passwords.
Another approach to reducing password complexity for users is to leave password systems in place but to automatically populate them when required. This moves the responsibility of remembering and typing multiple login IDs and passwords from users to an automated process.
This approach is the "enterprise single sign-on" (E-SSO) method. Typically, a set of application login ID / password pairs is stored for every user. Storage may be in an encrypted file, in a central database or in an extension to a network operating system's security directory -- typically Microsoft Active Directory or Novell eDirectory.
E-SSO is attractive because it addresses not only the user burden of remembering multiple passwords, but also the user nuisance of having to type them repeatedly. It also allows organizations to deploy a primary authentication system such as smart cards or one-time-password tokens instead of passwords, without having to rearchitect every password-secured application.
The limitations of E-SSO include:
Many argue that passwords have intrinsic limitations:
Both of these points are debatable -- for example, passwords have the distinct advantage of requiring no special hardware and being absolutely portable, and passwords that are sufficiently complex and changed often enough can be quite secure.
Nonetheless, many organizations address these (perceived or real) limitations of passwords by deploying other authentication technologies.
Authentication is fundamentally based on one or more of three approaches or three types of authentication factors:
Authentication factors other than passwords are rarely used alone. They are usually accompanied into a multi-factor authentication system, which is considered more secure than single factor authentication. Following are the most common systems:
The presence of a password or PIN in each of the above combinations indicates that passwords (and PINs are just short, numeric passwords) normally remain in widespread use even in those organizations that "replace" passwords with other technologies.
Most of the above systems also requires a backup authentication method. For example, a smart card user may forget their smart card at home or wish to access web-mail or another application from a device not equipped with a smart card reader. These users often have a backup, very complex passwords. Similarly, users who have trouble with their OTP token may request an emergency access code and users who wish to access an application from a device without a finger print or finger vein reader will need a backup password.
These "boundary condition" scenarios highlight the need to continue to support passwords alone as a backup authentication method, or risk losing access to systems and applications in some situations.
A traditional E-SSO system incorporates several components:
Stores encrypted application login IDs and passwords for every user. This may be in a file, the user's directory object or a database.
Detects when applications are launched and inserts credentials from the database into login prompts.
Tell the client software what credentials to populate into which fields on the screen.
These components interact in a variety of ways:
The E-SSO client software is installed on user workstations. Scripts are also initially deployed and may be periodically updated.
A developer, system administrator or even end users writes scripts for every application that will be integrated. A graphical framework may be provided to assist.
A script may detect a user's first use of an application and capture the user's login ID and password.
A script may detect when a user's password in an application has expired (i.e., the application asks the user to choose a new password). In this case, the script may either ask the user to choose a new password or may generate a random password. Regardless, the new password will be inserted back into the credential database.
As described earlier, a key component of a traditional E-SSO system is the credential database. Since it contains sensitive data specific to a given user, it must be encrypted, and each user should have a different encryption key. To prevent unauthorized access to application passwords by anyone other than the intended user, the key is based on the user's primary authentication.
This is a very important point and bears repeating: application passwords are encrypted using an encryption key derived from the user's primary authentication.
This fact leads to some important problems. Different problems arise depending on how users are authenticated in the first place:
Operational and security problems that result
If a user forgets his primary password, he effectively loses
access to all of his other passwords.
To address this, the E-SSO system must provide a second credential database, normally on a central server infrastructure, which uses a shared (not user specific) encryption key. This second credential database is used to reset forgotten primary passwords without having to recover or replace each and every application password as well. Deploying a secondary credential database adds cost to the system and raises a security risk -- the secondary system is an attractive target for intruders.
If a user loses his smart card, he is locked out of every
application, not just the primary PC login.
A backup credential database is needed in this case as well,
for the same reasons and with the same problems as above.
One time password
There is no way to generate a static, secret encryption key
from an OTP pass-code. It follows that the credential database
must be encrypted using a shared or hidden key, rather than
using a key calculated from something the user typed or plugged
An intruder may be able to find the encryption key in this
scenario and use it to unlock at a minimum every application
password for a single user and at worst every application
password for every user.
There is no way to compute a consistent, static, secret encryption
key from a biometric measurement of a user.
This means that, as with one time passwords, the credential database is encrypted using a key that is available in the user's absence. An intruder may be able to find the key and unlock either all of the user's passwords or possibly every password belonging to every user.
It is possible to store an encryption key on a proximity
card, but the key may be vulnerable to disclosure using an
unauthorized RFID reader. Some implementations may also use a
hidden key that as with biometrics and OTP tokens. In any case,
at least the user's passwords, and possibly all passwords, may
To summarize the foregoing, storing user passwords in a credential database may lead to some combination of the following problems:
These are all serious problems!
Another issue that arises when application passwords are stored in a credential database is that, over time, users come to depend on this database and may no longer know their own password.
This is not a problem when users sign into applications from a computer equipped with the E-SSO software, but creates issues when a user attempts to sign into the same application from another device.
Users increasingly access applications using smart phones, using their home PCs, using Internet kiosks and even using a telephony / voice user interface. In a typical E-SSO software deployment, none of these devices is equipped with the E-SSO client software, so none of these devices is able to access the credential database and use it to sign the user into applications.
This creates a serious usability problem: while the E-SSO software may work well from the user's work computer, it also makes applications inaccessible on other devices. This is contrary to the trend of an increasingly mobile workforce using an increasingly wide array of devices to access the network.
There are various approaches to overcoming this problem, but none of them is satisfactory:
The previous sections outline some of the approaches to reducing password complexity and some of the challenges that arise with enterprise single sign-on (E-SSO) in particular.
In practice, there is no reason to use just one approach. Best practice is most likely to combine:
A review of the deployment challenges specific to E-SSO, as described in the previous section, highlights the fact that a key challenge is building, populating, supporting and securing the credential database.
With this in mind, a new approach can be considered: eliminating the credential database entirely and replacing it with a password synchronization process. This is precisely the approach taken by Login Manager.
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 Login Manager architecture is illustrated in Figure [link].
Login Manager: Internal Components / Architecture (1)
In the diagram:
In some cases, organizations have a legitimate reason to prevent users from knowing their own application passwords. For example, consider a legacy client/server application, where:
The security flaw in this architecture is that the user could connect directly to the back end database with its native SQL client -- for example, sqlplus for Oracle databases, isql for Microsoft SQL Server, etc. Using this connection, the user could bypass all of the application's access control rules.
While this is clearly a broken security model, applications built this way remain widely deployed.
The security compromise described here can be avoided by regularly changing the user's application password and not allowing the user to know what that password is. Instead, the user is "locked into" the E-SSO client, which is the only entity that can retrieve the user's password and sign the user into the application.
This scenario can be implemented by combining three Hitachi ID Systems products:
The obvious downside of this scenario is that users can only sign into insecure applications from computers equipped with Login Manager -- they cannot sign in from a smart phone, home PC, etc. That is the price for locking down insecure applications.
Login Manager, a module included with Password Manager, is an enterprise single sign-on solution. It automatically signs users into applications where the ID and/or passwords are the same ones users type to sign into Windows on their PC.
Login Manager leverages password synchronization instead of stored passwords. This means that it does not require a wallet and that users can continue to sign into their applications from devices other than their corporate PC -- such as a smart phone or tablet -- for which a single sign-on client may not be available.
Login Manager does not require scripting or a credential vault, so has a much lower total cost of ownership (TCO) than alternative single sign-on tools.
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.