Selecting a Password Management Product
Upcoming SlideShare
Loading in...5
×
 

Selecting a Password Management Product

on

  • 852 views

 

Statistics

Views

Total Views
852
Views on SlideShare
852
Embed Views
0

Actions

Likes
0
Downloads
17
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Selecting a Password Management Product Selecting a Password Management Product Document Transcript

  • 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 Simplified 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.2.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Assisted Password Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Target Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4 Technology Considerations 10 4.1 Scalability and Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 i
  • Selecting a Password Management Product 4.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5 Deployment and Ongoing Administration 13 5.1 Deployability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 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. View slide
  • Selecting a Password Management Product 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 justification. 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 View slide
  • Selecting a Password Management Product 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 2
  • Selecting a Password Management Product 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 3
  • Selecting a Password Management Product 3 Functional Requirements The business requirements set out in Section 2 on Page 2 can be mapped to specific 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 4
  • Selecting a Password Management Product * 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 5
  • Selecting a Password Management Product 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 6
  • Selecting a Password Management Product 3.2.2 Pitfalls to Avoid 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 7
  • Selecting a Password Management Product 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). 3.3.2 Pitfalls to Avoid • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 8
  • Selecting a Password Management Product • 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. 3.4.2 Pitfalls to Avoid • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 9
  • Selecting a Password Management Product 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 profile) 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. 4.1.2 Pitfalls to Avoid Implementing a scalable, high-availability transactional system is difficult 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 10
  • Selecting a Password Management Product • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 11
  • Selecting a Password Management Product 4.2.2 Pitfalls to Avoid • 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! © 2014 Hitachi ID Systems, Inc.. All rights reserved. 12
  • Selecting a Password Management Product 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. 5.1.2 Pitfalls to Avoid • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 13
  • Selecting a Password Management Product 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 © 2014 Hitachi ID Systems, Inc.. All rights reserved. 14
  • Selecting a Password Management Product • 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. 5.2.2 Pitfalls to Avoid • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 15
  • Selecting a Password Management Product 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 16
  • Selecting a Password Management Product It follows that the vendor should have at least some expertise with each of these types of systems. This is a difficult 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 17
  • Selecting a Password Management Product 7 Conclusions As described in this document, a password management system is conceptually simple, but can be difficult 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 difficult 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