Selecting a Password Management Product

Selecting a Password Management Product
© 2014 Hitachi ID Systems, Inc. All rights reserved.

This document is intended to help organizations set out criteria which can be used to select a password
management product.
The selection process begins with a business case for a password management system. The business
case is used to develop functional and technical requirements, which in turn drive the product and vendor
selection process.
Contents
1 Introduction 1
2 Business Case for Password Management 2
2.1 Support Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Simpliﬁed Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Improving Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.4 User Convenience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Functional Requirements 4
3.1 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Self-Service Password Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Assisted Password Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Target Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Technology Considerations 10
4.1 Scalability and Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
i

4.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5 Deployment and Ongoing Administration 13
5.1 Deployability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6 Vendor Viability and Commitment 16
6.1 Breadth of vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 Viable business and stable products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3 Services Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Conclusions 18
© 2014 Hitachi ID Systems, Inc. All rights reserved.

1 Introduction
This document is intended to help organizations set out criteria which can be used to select a password
management product.
The selection process begins with a business case for a password management system. The business
case is used to develop functional and technical requirements, which in turn drive the product and vendor
selection process.
The remainder of this document is organized as follows:
• Business case for password management
Every password management project must begin with a business justiﬁcation. This is the background
for all subsequent requirements.
• Functional requirements
Basic functions that every password management system should meet.
• Technology considerations
Technical architecture considerations and how they impact a password management system’s usabil-
ity.
• Deployment and management
Design considerations that impact the initial deployment and ongoing administration of a password
management system.
• Vendor quality
The qualities of a successful password management vendor.
• Conclusions
A summary and a reminder to “try before you buy.”
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

2 Business Case for Password Management
A password management system should not be deployed based solely on a vendor’s recommendation.
Rather, it should address real and measurable business problems and should yield a measurable return on
investment (ROI).
Following are the most common reasons for deploying a password management system:
2.1 Support Costs
According to IT analyst firms such as Gartner, Forrester and Burton, 20% to 30% of total call volume at the
IT help desk in a typical medium to large organization is due to login problems, which are most commonly
caused by forgotten passwords or users who triggered an intruder lockout mechanism.
Collectively, these problems are costly to resolve. They also represent a significant user productivity cost
– for every hour spent by the help desk resetting passwords for callers, end users spend two hours coping
with login problems.
A password management system should address this cost, by reducing both problem frequency and the
cost to resolve password problems.
2.2 Simplified Administration
Many organizations have multiple user directories. For example, a large company may deploy an Active
Directory environment for network login and e-mail a Sun ONE directory for Unix-hosted Intranet authenti-
cation and a variety of additional user ID/password databases embedded in other systems and applications.
Provisioning and managing passwords in multiple systems is difficult and a password management system
can streamline this process.
2.3 Improving Security
Most users prefer to use simple passwords. They prefer to keep the same password for a long time. If they
must have many different passwords, they tend to write them down, because they are too hard to remember.
IT security, on the other hand, prefers that users have complex passwords, change their passwords often
and never write down or share their passwords. These are often centrally dictated policies.
A password management system can be used to enforce some of these security rules, including rules
that existing systems cannot enforce. It can also make rules easier for users to follow – e.g., one strong
password that users can remember rather than ten strong passwords that the user writes down.

2.4 User Convenience
Most users have to authenticate to multiple systems, each of which maintains its own password, its own
password policy rules and its own expiration schedule.
When users manage each password separately, they tend to accumulate multiple, different passwords
which expire on different dates.
A password management system should simplify this: allowing users to manage just one or two passwords
across all systems, changing all passwords on a single schedule and subjecting all passwords to a single,
combined set of rules. This improves the user experience and reduces the frequency of users forgetting or
writing down their passwords.

3 Functional Requirements
The business requirements set out in Section 2 on Page 2 can be mapped to speciﬁc functional require-
ments:
3.1 Synchronization
Most user login and password problems are due to users forgetting their passwords or typing one system’s
password into another system’s login prompt.
The fundamental solution to this problem is to simplify password management for users and the easiest
way to do that is to synchronize passwords.
Most systems store passwords as hashes. Hashes are different from encryption in that they are not re-
versible – you can compute the hash of a string, but you cannot get the string back from its hash.
Plaintext passwords are used to calculate hashed passwords. When this is done at different times: when
the password is set and again when the password is validated, hashing is used to check that the password
a user typed at login time is the same one he typed when he previously chose his password.
The reverse operation – calculating a plaintext password from the hash – is mathematically (almost) impos-
sible. Since different systems use different hashing methods, it is also impossible to copy password hash
values from one system to another.
Use of different hashing algorithms means that password synchronization must happen when users enter
a new password value – since at that time (and only at that time) the new password is available in plaintext
and different password hashes – one for each system where the user has a password – can be calculated
from a single plaintext value.
3.1.1 Requirements
A password synchronization must meet the following requirements:
• Provide a way for users to select a new password for all of their login accounts.
• Be easy to use, to support user adoption.
Simplicity and high user adoption be achieved by either extending an existing password change pro-
cess or creating a friendly new method for changing passwords:
– Extending an existing password change process to trigger synchronization: For example, when
users change their Active Directory password, the new password can be automatically forwarded
to their other login accounts. (this is called transparent password synchronization)
– Provide a new password change process: Most users are comfortable with web browser, so
a web form can be introduced that lets users step through the following process: (web-based
password synchronization)
* User types his login ID.

* User types his current login password.
* User types a new, desired password (twice).
* The password synchronization sets the user’s password on multiple systems to the same
new value.
3.1.2 Pitfalls to Avoid
While the above processes are simple, a poor implementation can result in low user adoption or total system
failure:
• User profiles:
Any password management system must either contain or have access to a database of user profiles.
It must, at a minimum, know what user ID each user types to log into each managed system.
If user IDs are consistent (any given user has just one ID, which works on every system), then building
this user profile database is simple.
If user IDs are different, as may be the case with legacy systems or after corporate mergers and
acquisitions, this data is hard to come by and may require a massive data load at the project outset.
Once user ID profiles are initially loaded into the system, they must be maintained, because users are
added to and removed from every system in the course of normal system management.
A mature password management system must include automation to build, maintain and correlate
user IDs. Failure to include this automation translates into a massive deployment project followed by
costly ongoing administration.
• Web-based password synchronization:
– The process must be extremely simple.
– Users must be automatically prompted to use the synchronization system. Users do not volunteer
to change their own passwords.
– Users should be authenticated using a current password:
* The system must not introduce a new password, as that increases complexity.
* The system must not ask users to answer a series of personal questions to authenticate, as
this is awkward and many users may perceive it to be an invasion of privacy.
• Transparent password synchronization:
– The system should be extremely reliable, since users do not interact with it directly. This means:
* Multiple load-balancing servers in a high-availability configuration.
* Automatic retry of failed synchronization.
* User notification of both successful completion and errors.
• Password policy:
A uniform password policy should be developed, to simplify the rule set that users must understand.
• Education:
Users must be educated about how to use the system and how it impacts them.

3.2 Self-Service Password Reset
Password synchronization should reduce password problem frequency, but users will still experience some
password problems. To address these remaining problems, users should be offered a self-service system,
so that they can resolve their own problems without calling the help desk.
3.2.1 Requirements
A self-service password reset system should be:
• Accessible when needed
Users should be able to access the system and should know that it’s available, wherever they may
require a password reset. This includes from their workstation login prompt, from a web browser
inside and in some cases outside the corporate network and using a telephone.
• Easy to use
The user interface, whether integrated into a login page, embedded in a web browser or accessed
using a telephone, should be easy to use and require no training.
• Secure
When a user forgets his password, some other form of authentication is needed before the user
can be issued a new password. This alternate authentication must be as secure as possible, since
it effectively substitutes for the user’s password. A password management system should support
authentication factors such as hardware tokens, biometrics, multiple sets of both pre-defined and
user-defined personal questions, etc.
Other essential security features include encrypted transmission and storage of personal or authen-
ticating data, detailed audit logs, intruder lockout if the user fails authentication multiple times and
security incident alarms.
• Integrated
Most organizations track IT support incidents in a help desk application. A mature password man-
agement system should automatically create incident for both successful password resets and for
anomalous events (errors, failed authentications, configuration problems, etc.).
• Flexible
Medium to large organizations often need to adapt off-the-shelf software to meet their unique needs.
A successful password management system should cope with unique requirements, such as:
– User interface customization and language translation.
– Supporting various authentication technologies.
– Enforcing various password policy requirements.
– Integrating with incident management systems and implementing appropriate logic regarding
how and when incidents are created, updated and closed.

Self-service password reset is a simple concept, but implementation can be challenging:
• Is it really accessible?
The system should be readily accessible from login prompts and by users both inside and outside
the corporate network. The system should work across firewalls. It should be able to reset VPN
passwords.
• Is client software required?
Any solution requiring client software to be deployed will impact desktop support. If the software
is technologically invasive, it may impact the core operating system of user PCs. Deployment and
support cost for client software can in some cases outweigh the benefit of self-service password
reset.
• Where does the authentication data come from?
Primarily to reduce cost, most organizations choose a question-and-answer model for authenticating
users who forget their passwords. This data must come from somewhere: the HR system, a corporate
directory or self-service registration by users.
If the data already exists, it must be keyed to network login IDs. Mapping this data to login IDs can be
time consuming and expensive.
If the data does not exist, then an application is required to ask users to fill in their own profiles, to
authenticate them when they do so and to remind users if they don’t respond to the first invitation.
Authenticating users to register Q&A data using a current password is secure and manageable. Au-
thenticating users with PINs or other data distributed by post or e-mail is insecure and difficult to
manage.
• Imprecise matching of authentication data
Users who have registered personal data, such as ancestor surnames, place names, etc., are liable
to type this data differently on different occasions. For example, is a user’s mother’s maiden name
Smith, smith or Smythe? The user may have enrolled one of these and later try to authenticate
with another.
A password reset system should tolerate some variations in user input, to ensure a successful user
experience.
• Is there a plan to drive user adoption?
Most users do not automatically use a self-service tool just because it is there. They must be educated
about it, prompted to use it, rewarded if they use it and in some cases should receive a lower standard
of service if they don’t. This requires planning and technical capabilities to monitor and react to usage.
3.3 Assisted Password Reset
Inevitably, users will forget their password (despite synchronization) and call the help desk (despite the
availability of self-service).
A password management system should streamline the resolution of these calls.

3.3.1 Requirements
A password management system should be able to handle every detail of a password problem call, includ-
ing:
• Authenticate the help desk support staff.
• Identify the caller.
• Authenticate the caller.
• Get a list of the caller’s login IDs.
• Reset one or more passwords.
• Clear intruder lockout flags.
• Report on results.
• Create (and in most cases close) an incident in the help desk system.
• Report on the activity to the user (normally e-mail).
• Help desk support staff authentication
Help desk support staff have powerful access to a password management system, with the ability to
reset any user’s passwords. They should have to authenticate using a strong mechanism, such as a
strong password or a hardware token.
Using a personal Q&A profile or a weak or static password is not acceptable for help desk users, even
in cases where it is acceptable for end-users.
Allowing help desk support staff to share accounts is similarly not acceptable.
• Caller authentication
A help desk typically authenticates callers by asking them to respond to a sequence of personal
questions and comparing what they say to data on a user profile system.
Some personal user information may be considered private. Depending on local legislation and cor-
porate policy rules, personal data used for authentication may have to be used in one of two ways:
– Different sets of personal data may be used for self-service authentication and for assisted ser-
vice.
– Help desk support staff may not be allowed to see personal user data, but must instead type it
into an authentication form.
• Imprecise matching of authentication data
It is important for help desk support staff to be able to mis-type answers to personal user questions
and still get a successful match. This is because users tell the help desk support staff what to type
over a telephone and this transcription is very error-prone.

• Incident management system integration
An assisted-service password reset system must be able to automatically create incidents in a help
desk system, as described above.
This integration must be extremely flexible, because the quantity, type and contents of incidents cre-
ated and e-mails sent will vary based on circumstances and corporate rules.
Consider an example:
– When a password is reset successfully, a closed incident should be written to the incident man-
agement system and an e-mail sent to the user.
– When a password reset attempt fails with an error (for example, managed system unavailable),
an open incident should be written to the incident management system about the service event,
an e-mail detailing what worked and what didn’t should be sent to the user and a second open
incident should be written to the incident management system, assigned to an individual system
administrator, asking for service.
This degree of flexibility ensures that help desk support staff do not have to manually create incidents
to match the work they already completed in the password management system.
3.4 Target Systems
A password management system is only valuable if it supports the systems where users actually have
passwords. A rich set of included connectors and simple integration with supported types of systems is
desirable.
3.4.1 Requirements
• Broad platform support
The password management system should support password management on systems that represent
at least 90% of the password support calls that reach its IT help desk.
• Extensible integration
Integration with new, custom or vertical market applications should be easy.
• Low/no cost for increased coverage
It should be relatively painless to add integrations to new systems.
• Some vendors only offer a handful of built-in platform connectors / agents.
• Some products require invasive agents to be installed locally on integrated systems and applications
(i.e., change control).
• Integration with new target types or applications may require extensive and costly programming.
• Some vendors charge significant amounts of money for additional connectors / agents.

4 Technology Considerations
4.1 Scalability and Availability
A password management system must scale to handle the peak transaction volume generated in an orga-
nization. Once established, it normally becomes a core IT infrastructure service and must remain highly
available.
4.1.1 Requirements
• Peak transaction rates
Self-service and help desk password reset features support users who forget their passwords. This
happens about 2-3 times per user per year and normally on Monday mornings.
Password synchronization is triggered by password changes and impact every user every 2-3 months.
Again, password changes and synchronization happen in the morning.
In practice, a password management system may have to support a peak rate of 3,000 password
changes/hour for every 10,000 users. This load is often best served using multiple, load balanced
servers.
• Multiple servers
For both the scalability reasons mentioned above and to meet the requirement for high availability,
most organizations should deploy at least two password management servers.
Servers should include data replication, so that updates to one (e.g., new data in a user proﬁle) should
be automatically replicated to the other.
Servers should be load-balancing – which means that users should be automatically directed to one
of multiple active servers.
Servers should be monitored and failures should trigger automatic removal of a server from load
balancing circulation.
Implementing a scalable, high-availability transactional system is difﬁcult and many vendors make mistakes.
Following are some common problems:
• Multiple servers, single database
Having multiple password management servers that use a single back-end database does not improve
availability – it just moves the single point of failure to another part of the architecture (the network).
To be truly robust, the system must support one database server per password management server,
with real time replication between servers. This eliminates any single point of failure.
• Fail-over rather than fail-out
Some systems implement a “hot standby” server rather than load balancing between multiple active
servers and removing malfunctioning servers automatically, if required.
Using a standby server is a waste of capacity and a limitation of maximum scalability.

• Attaching users to specific servers
Some systems attempt to scale by assigning specific user groups (e.g., based on the first letter of
their login ID) to specific servers.
While this approach does scale, it does not address the high availability requirement, is difficult to
manage and may not be user-friendly.
4.2 Security
A password management system is a sensitive part of the I.T. infrastructure because it can reset any user’s
password on any system and because it either contains or can access confidential user profile data.
This sensitivity means that a password management system must be managed securely.
4.2.1 Requirements
• Host platform
The password management server must be able to run on a hardened host operating system, with a
hardened web server.
While every operating system and web server has a history of at least some security vulnerabilities,
these vulnerabilities are inevitably due to a flaw in one subsystem or another. By disabling non-
essential subsystems, it is possible to reduce the likelihood of future problems.
• Use of encryption
All sensitive data, be it transmitted or stored, should be encrypted or hashed, as appropriate. This
means using HTTPS from the client web interface to the password server and suitable protocols to
encrypt data going from the password server to managed systems or back-end databases.
• User authentication
A password management system that includes self-service password reset in effect makes passwords
and non-password authentication equivalent.
Passwords, especially if they are changed frequently and comply with reasonable complexity rules,
are fairly secure. Accordingly, it makes sense to use strong profiles of authentication data or hardware
tokens if possible, as the non-password authentication system.
If Q&A profiles are used as the non-password authentication system, they should include multiple sets
of questions, with separate requirements and usage for each. In particular, users should be required
to answer some pre-defined questions to ensure quality and in addition should have to define some
of their own question/answer pairs, to ensure that every profile is unique.
• Trust relationships
The password server should not trust other systems. It should not be possible for the administrator of
another system to abuse such trust to gain control over the password system. In practice, this gen-
erally means that a password management server should not be a member of a NOS domain, where
domain administrators can also sign into the password management server as local administrators.

• Host platform
Some operating system components to avoid or disable, because of their history of security problems,
include:
– IIS and in particular Active Server Pages.
– File sharing and in particular NFS and SMB.
– “Simple network services” such as echo and time-of-day.
– Windows services such as COM, DCOM and DDE.
Ideally, a password management system should be able to run on a stripped-down server, with only a
web service running and preferably a web server such as Apache with almost every module disabled.
• Working with web proxies and firewalls
It is desirable to be able to install a password management server in a secure subnet, behind a
reverse web proxy. This eliminates any possibility that an attacker could connect to any service on the
password server directly.
This implies that all communication from users to the password server be carried over pure HTTPS.
A password management server should not incorporate an application-level protocol from a client
software component (ideally there should be no client software) and the server.
• “API security”
Some password management products rely on third-party vendors to encrypt their native communica-
tion protocols. They assume that if a native API was used to manage passwords on a given system,
then that communication must be secure.
This is nonsense. Many native protocols, such as those used by Oracle (SQL*Net), MSSQL (TDS)
and SAP (CPIC), are vulnerable to attacks by packet sniffers and man-in-the-middle attacks.
A password management server must include some provision to protect communication with every
target system, even when its native protocol is insecure.
Encrypting communication with insecure managed systems can only be done by installing an agent
on the managed system or installing a secure application-level proxy server that is co-located in a
secure environment with the managed system.
• Strong user authentication
User authentication should be strong at all times. In practice, this means:
– Using a current password and not a PIN when users sign in to enroll.
– Using hardware tokens if possible for non-password authentication.
– Using multiple sets of questions, both standard and free-form, for challenge-response authenti-
cation.
– Implementing intruder lockout and alarms when there are repeated authentication failures.
• Using a real certificate authority
Some products use SSL to encrypt communication between their clients (web-based) and their own
server, but use a private, vendor-supplied certificate to initiate this communication.
Password vendors are not certificate authorities and should not issue their own cryptographic certifi-
cates!

5 Deployment and Ongoing Administration
5.1 Deployability
The main reason for installing a password management system is normally to achieve cost savings. If the
system is difficult or costly to deploy, those savings are offset by unreasonably high initial cost and may be
delayed unacceptably.
Accordingly, rapid and inexpensive deployment is essential to a worthwhile password management system.
5.1.1 Requirements
• No requirement for client software
Deploying client-side software in a large organization can be costly. Consider the problems created
by pushing software to thousands of workstations, each of which may run a different operating system
version or patchlevel and each of which may have a different configuration.
The cost of deploying client-side software may be prohibitive and should be avoided if possible.
• Automatic discovery of managed user IDs
Every password management system must have a profile for each user, that connects that user with
his login IDs on managed systems.
A password management system should construct this profile automatically. Where automatic dis-
covery of this profile data is not possible, the password management system should invite users to
populate their own profile data.
• Self-contained system
A password management system should be simple to install, which generally means that it should
be self-contained. Reliance on external infrastructure, such as a corporate directory, meta directory
product, HR database or incident management system is undesirable.
Self-reliance is also an important attribute for high-availability, as it makes it simpler to engineer a
redundant solution, with no single-point-of-failure.
• Minimal change control on integrated systems
Installing agents on production servers is costly, as it normally entails a change control and quality
testing process. If a password management system can integrate with a system without installing local
agents, it will be much simpler to install and administrators of that system will have fewer objections
to its deployment.
• MSGINA.DLL
A key problem in a password management system is how to empower users who forget their initial
network password to access a self-service password reset. Most password management systems are
web-based, but users who forget their initial login password cannot access their own desktop and so
cannot launch a web browser.

On Windows NT, 2000 and XP workstations, the login screen is implemented by and can be extended
by manipulating the Graphical Identification and Authentication (GINA) DLL.
Some vendors address this problem by installing client-side software which replaces or wraps around
the Microsoft GINA DLL. This gives their products the ability to introduce new user interface compo-
nents at the login prompt – notably a button that users who forget their passwords can click to activate
a self-service password reset user interface.
Wrapping or replacing the native Microsoft GINA DLL is usually undesirable:
– It requires client-side software, which is undesirable in general.
– A bug, failed installation or service-pack-incompatibility in the 3rd-party GINA DLL can render
affected workstations inoperable – such workstations may have to be re-imaged.
– Some network operating system1
, hard disk encryption2
and authentication technology3
vendors
already replace or wrap the native Microsoft GINA DLL. This raises the problem of compatibility
between a 3rd-party GINA DLL provided by a password management vendor and other 3rd-party
GINA DLLs from other software vendors.
The same problem can be resolved without a client-side software deployment (using a secure kiosk
account) or with client-side software that does not replace the GINA DLL (using a service that adds a
button to an already-running GINA screen). Consequently, deploying a GINA wrapper DLL represents
an unnecessary project risk.
• A massive data load
As described earlier, a password management system by definition requires a profile for each user.
The profile must include a set of challenge/response data used to authenticate users who forget their
password, a list of login IDs that belong to the user and possibly additional data about the state of the
user’s profile.
To the extent possible, this data should be produced through a combination of auto-discovery and
self-service enrollment.
Some vendors approach this data set as an opportunity to sell professional services. Organizations
should beware costly deployment projects and ongoing data maintenance requirements. A manual
data load by external consultants can easily be the largest cost component of a deployment project
and may delay production roll-out by months.
5.2 Administration
As with deployability, the ongoing cost and effort required to maintain a password management system
should be minimal.
5.2.1 Requirements
• Database administration
A password management system should not require the ongoing intervention of a database adminis-
trator, either to manage the DBMS server infrastructure or to maintain the contents of a user-profile
database.
1Novell
2Checkpoint
3RSA

• Automatic discovery and registration of new users
Organizations onboard (hire), deactivate (terminate) and move people constantly. These business
events can produce a high volume of changes to the list of users in each security database and
consequently to the list of users that a password management system must support.
A password management system should automatically detect new and deleted users on integrated
systems, so that it can automatically add and remove user profiles and login IDs in its own database.
In addition, users should be able to update their own profiles, to attach existing login IDs that were
not automatically detected or automatically attached by the password management system. This can
significantly reduce the need for administrative intervention in the day-to-day operation of the system.
• Double entry book-keeping
Some password management systems do not support auto-discovery of users and login IDs on target
systems or allowing users to attach their own login IDs to their own profiles.
In these cases, the administrator of a password management system must manually make entries to
reflect new and removed users on target systems. This is costly, error-prone and undesirable.

6 Vendor Viability and Commitment
Password management systems typically have a lifespan of several years and this time interval spans
multiple infrastructure upgrades addition and removal of applications and changes to business processes.
A password management system must be supported by a capable and stable vendor. A vendor with poor
skills or vision will be unable to properly support its product. A vendor whose business may not be viable or
whose focus may shift away from password management will not offer adequate support to customers.
6.1 Breadth of vision
The password management market is a part of a larger user provisioning and identity management market.
To be viable, vendors must provide a broader set of functionality beyond just password management.
6.2 Viable business and stable products
A vendor who goes out of business cannot offer long-term support for its products.
Similarly, a vendor who is acquired may not offer support for some products, as some may be retired or
replaced by products offered by the new parent company.
6.3 Services Organization
A password management vendor must support integration with a diversity of existing infrastructure, includ-
ing:
• Network operating systems.
• Mainframes and minicomputers.
• Directories.
• DBMS servers.
• ERP and other applications.
• E-mail systems.
• Web infrastructure.
• Incident management systems.
• Authentication hardware (tokens).
• Interactive Voice Response (IVR) servers.

It follows that the vendor should have at least some expertise with each of these types of systems.
This is a difﬁcult challenge for any single vendor to meet. Accordingly, it is prudent to try the product and at
the same time evaluate the vendor’s ability to support these various integrations, before purchasing.

7 Conclusions
As described in this document, a password management system is conceptually simple, but can be difﬁcult
to deploy and to manage.
A careful examination of products and their vendors is essential to achieving:
• Rapid deployment.
• Reliable and scalable operation.
• Good user adoption.
• Long term support.
Without meeting these objectives, a password management system will not achieve reduced cost, improved
user service or enhanced security.
The issues raised here are difﬁcult to validate on paper. Hitachi ID encourages prospective customers to
use the points raised in this document to construct rigorous laboratory testing conditions and to evaluate
prospective products empirically, with vendor assistance.
www.Hitachi-ID.com
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
File: /pub/wp/documents/selecting_pw_product/selecting_pw_product_8.tex
Date: 2009-05-11

Selecting a Password Management Product

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Selecting a Password Management Product

Similar a Selecting a Password Management Product (20)

Más de Hitachi ID Systems, Inc.

Más de Hitachi ID Systems, Inc. (20)

Último

Último (20)

Selecting a Password Management Product