From Password Reset to Authentication Management: the Evolution of Password Management Technology

Transcription

1 From Password Reset to Authentication Management: the Evolution of Password Management Technology 2010 Hitachi ID Systems, Inc. All rights reserved.

2 Contents 1 Introduction 1 2 In the Beginning: A Simple Problem 2 3 Proliferation of Passwords Trend Impact on SSPR infrastructure Password synchronization Single sign-on Locked-out Users, Mobile Users and Cached Passwords 8 5 Multi-Factor Authentication: Smart Cards and Tokens 10 6 Public Key Infrastructure and Encrypted Key Files 12 7 Full Disk Encryption 14 8 User Enrollment and Adoption User awareness User enrollment Privileged Accounts and Passwords The Future Summary 23 APPENDICES 24 A Self-service password reset for locked out users 25 i

3 List of Tables 1. Self-Service Password Reset Overview Password Management Challenges due to Heterogeneous Systems Technical Challenges for Password Synchronization Complications to Self-Service Password Reset Multi-Factor Authentication Options Multi-Factor Authentication: User Support Processes Multi-Factor Authentication: User Support Processes Technical Challenges for Smart Card PIN Reset Support and Security Challenges in Public Key Infrastructures Support and Security Challenges in Public Key Infrastructures Process Overview for Full Disk Encryption Security and Support Challenges for Full Disk Encryption Security and Support Challenges for Full Disk Encryption Optimal User Interface Placement to Maximize User Awareness Types of Data Which May Require User Enrollment Technical Features of a Robust User Enrollment Management System Technical Features of a Robust User Enrollment Management System Types of Privileged Accounts and Why They Use Passwords Security Vulnerabilities Associated With Privileged Accounts Technical Characteristics of a Robust System for Managing Privileged Passwords ii

4 1 Introduction Over the years, password management software has evolved from a simple self-service web application to reset forgotten passwords to a complex platform for managing multiple authentication factors and encryption keys. This document describes the technological evolution and highlights the product capabilities that organizations should consider in order to have a lasting value from their investment. In part, this document questions the benefits of investing in point solutions with limited functionality and expansion capabilities and in favor of investing in a platform capable of addressing both short- and longterm needs Hitachi ID Systems, Inc. All rights reserved. 1

5 2 In the Beginning: A Simple Problem Password management products started out in the mid 1990 s as simply self-service password reset (SSPR). Many products on the market today still support only this function. Self-service password reset programs can be described as follows: Business challenge: Security exposure: Root cause analysis: Solution: More detail: Solution benefit: Table 1. Self-Service Password Reset Overview The IT help desk is inundated with calls from users who forgot or locked out their password. This can be as much as 35% of total IT support call volume and reaches a peak during the first morning of each work week. The help desk password reset process is often vulnerable to security exploits. The analysts in most help desk organizations can be fooled into resetting passwords for an impostor who either sounds too important to challenge or who can correctly answer the questions a help desk analyst asks a caller in order to authenticate that caller. Users forget their passwords because: they have too many; they change passwords right before leaving work for the weekend or a holiday; or password complexity rules make passwords hard to remember. Users trigger lockouts by typing old passwords or by failing to notice the state of the Caps Lock or Num Lock keys on their keyboards. Use a web application where users can authenticate by answering a series of security questions instead of typing their password. Users can then choose a new password without calling the help desk. Security questions and answers may not be available for all users, or may be inadequate to the task of reliable authentication. As a result, an enrollment web application is also required, where users can authenticate with their password and complete their profile with answers to security questions. The call volume at a typical IT help desk can be reduced by as much as 25%, so long as the system is effective and the user adoption rate is high Hitachi ID Systems, Inc. All rights reserved. 2

6 3 Proliferation of Passwords 3.1 Trend Most medium to large organizations have a large number of applications, many with their own databases of login IDs and passwords. Some applications can leverage common platforms such as Active Directory to authenticate users, but many legacy applications cannot. Moreover, some applications which can externalize user authentication may have integration requirements that cannot be met by some organizations. This trend is improving, as illustrated in Figure 1, but it s clear that most organizations are trending towards several passwords per user, rather than just one: Mainframe LAN Client/Server Intranet Active Directory, Web SSO Multi-factor, PKI, HDD Encryption Figure 1: Trend in the number of corporate passwords per user At the time this document was written (2010), a typical corporate user has several passwords one Active Directory password plus one or more of the following: 1. A separate LDAP directory used to authenticate to Intranet web applications. 2. An ERP password SAP R/3, PeopleSoft, Oracle ebusiness Suite, etc. 3. A mainframe password - RAC/F, ACF/2 or TopSecret. 4. A PIN associated with a smart card or token. 5. A password used to unlock the encrypted hard drive on his PC. 6. One or more passwords on software as a service (SaaS) applications, such as SalesForce.com, Ceridian, ADP or others Hitachi ID Systems, Inc. All rights reserved. 3

7 3.2 Impact on SSPR infrastructure If it is to continue to function, the simple SSPR model described in Section 2 on Page 2 must overcome three basic challenges: Table 2. Password Management Challenges due to Heterogeneous Systems Challenge Details Impact on SSPR system Heterogeneous platforms: Multiple policies: Different login IDs: In order to continue to provide value, an SSPR system needs to be able to reset passwords on multiple systems not just the Windows environment. Each of the systems where the SSPR system will manage passwords may have its own password policy, regarding how often passwords must change and how they must be composed, so that they are hard to guess. Each system will also have different limitations regarding password length and what characters can be used in a password. Users may have different login IDs on different systems and applications. Multiple connectors are needed, each dedicated to managing passwords on a different kind of system. In other words, an AD connector, an LDAP connector, one or more mainframe connectors, one or more ERP connectors, database connectors, connectors for SaaS applications, etc. Must support a mix of password policies, to help users choose passwords that will actually work on selected systems. Must link inconsistent login IDs back to their (human) owners and their profiles of security questions and answers. 3.3 Password synchronization Given that one of the challenges facing users is simply having to manage too many passwords, it seems natural to synchronize passwords, so that users at least have fewer to remember. Password synchronization works by intercepting a password change on one system and propagating the new password value to other systems and applications where the same user has accounts. In practice, this is not as simple as it first appears. To make password synchronization scalable, secure and reliable, the following challenges must be overcome: 2010 Hitachi ID Systems, Inc. All rights reserved. 4

8 Table 3. Technical Challenges for Password Synchronization Challenge Details Impact on password synch. system Different password hashes Peak load Feedback Different systems and applications store passwords using different cryptographic hashing mechanisms. Since cryptographic hashes are not reversible (i.e., one cannot calculate the plaintext password value from the hash value stored in the password database) and since hashes are not compatible (the same plaintext password will yield different hashes on different systems), password synchronization cannot be done between two systems of different types by simply copying stored password values from one to another. Users tend to change their passwords only when forced to do so. This normally happens when they first sign into their computer at the beginning of the work day. Consequently, there is a burst of password changes (and resets, due to forgotten passwords) during the first hour of the first day of the work week. Indeed, up to 50% of all password changes in an entire week tend to happen during this one hour. This makes password synchronization workloads very bursty long periods of low activity punctuated by short periods of very high activity. If password synchronization is triggered by a password change on just one system for example, a native password change on AD or LDAP, or use of the password management software s own web UI, then the process is relatively straightforward. Complexity arises, however, if more than one system is configured to trigger password synchronization. When this is the case, a password change can form a feedback loop, as illustrated in Figure 2. To synchronize passwords between systems of different types, a plaintext password value is required. This is normally only available at the time a password is changed. Consequently, password synchronization must be implemented by capturing new passwords when they are set. A password management system must scale to handle very high peak workload up to 100 times more transactions per hour at peak than on average. Since any sort of feedback could overload the network, a password synchronization system must either forbid multiple triggers (not feasible in many organizations) or take steps to prevent feedback from happening at all. Peak password change frequency, mentioned above, bears further scrutiny. Consider an organization with 10,000 users, where the average user has 10 login IDs and passwords, and where passwords expire every 90 days (i.e., 4 times per year): 1. PU = minimum number of password changes per user per year = 10 4 = Hitachi ID Systems, Inc. All rights reserved. 5

9 1 User changes password System A 3 Trigger sent to a random PW mgmt server Password Management Server 1 Trigger code 2 Trigger PW synch 8 Trigger feedback 7 Set same password on another app System B 5 Trigger PW synch (again) Load Balancer Password Management Server 2 Trigger code 4 Set same password on another app 6 Trigger sent to a random server Figure 2: Password synchronization feedback 2. PT = minimum number of password changes per year for all users = 10, = 400, Assuming 2000 work hours/year, this comes to an average of 400, 000/2, 000 = 200 password changes/hour = 4 passwords/minute. 4. Assuming half all passwords are changed in the first hour of a 40-hour work-week, peak password changes per hour = 200/2 40 = 4000/hour = 67/minute = 1/second. These figures are illustrative only and only take into consideration routine password changes. They ignore high volumes of password changes and resets after holidays, for example, which can further amplify peak load. 3.4 Single sign-on Any discussion of password synchronization inevitably raises a comparison with single sign-on. Why not continue to have multiple passwords for every user, but store them somewhere and automatically fill them in? A detailed comparison of password synchronization and single sign-on is beyond the scope of this white paper, but some key differences to keep in mind are: 1. Password synchronization does not require software to be installed on every user PC. Eliminating the client component significantly reduces complexity and, therefore, costs and delays. 2. Password synchronization software does not store user passwords. This eliminates the need for a secure, reliable, distributed database where application credentials are stored Hitachi ID Systems, Inc. All rights reserved. 6

10 3. Password synchronization is not specific to a given device or client platform. It works just as well for users with Windows PCs, Linux, Macs or smart phones Hitachi ID Systems, Inc. All rights reserved. 7

11 4 Locked-out Users, Mobile Users and Cached Passwords Password reset using a web browser user interface is conceptually straightforward, but users often have problems that cannot be addressed by this simple model: 1. Locked out users: Users may forget or lock out their primary workstation login password. Since they have to type this password before they can launch a web browser, a pure web-based solution will not help them reset it. In many organizations, 40% or more of password-related support incidents relate to the primary password, so failing to address the problem of locked out users is not acceptable. 2. Cached passwords: Windows keeps a copy of a user s login password in memory and may offer that password to Windowshosted services on the network. While use of Kerberos in Active Directory should eliminate this practice, many applications in a typical organization continue to use NTLM-based authentication, so the password a user typed to sign into his PC will be offered to network services more often than Windows administrators may realize. Normally, this behavior is innocuous it simply eliminates the need for a user to re-authenticate when he accesses a shared folder or Intranet web application. A problem arises, however, when users perform the following sequence of steps: (a) Sign into their PC, with the current ID and password. (b) Sign into a web application and use it to change their Windows password. (c) Access other (unrelated) shares and web applications. Since the user s PC is unaware of the new password issued by the web application, it will continue to offer the old, no-longer-valid password to those services. If this happens often enough, the user s Windows password will be locked out due to too many attempts to use the obsolete password. 3. Mobile users: Users are increasingly mobile. They unplug their laptop PC from the corporate network and take it with them home, to an airport, a hotel, for example. Windows supports mobile users by caching their domain credentials locally (note: this is a persistent cache, unlike the in-memory one described above). Users can sign into their disconnected PC with cached credentials, enabling it to be used away from the corporate network. If a mobile user, whose PC contains cached credentials, forgets his password then the IT support process is quite complex. In many cases, the user may have to physically bring his PC back to work to resolve the problem, a very expensive and disruptive support incident. A password management system suitable for enterprise-scale deployment must address each of these problems: 2010 Hitachi ID Systems, Inc. All rights reserved. 8

12 Challenge Locked out users: Cached passwords: Mobile users: Table 4. Complications to Self-Service Password Reset Required capability A user interface must be exposed in the login screen of user PCs, so that users can initiate the self-service password reset process from the login prompt, without completing a normal login. There are multiple approaches to this problem, as described in Appendix A on Page 25 each of which represents its own, unique compromise between security, usability and deployment complexity. A simple solution to this problem is to ask users to sign off from their PC after every password change made through a web browser or over the phone. A more sophisticated and user-friendly solution is to execute an ActiveX component on the user s PC to refresh the cached password after it is changed on the network. The only practical way to address this problem, short of asking users to visit the office in order to reset a forgotten password, is to expose a UI element at the login screen (as described above) and have it setup a temporary VPN connection to the corporate network, over which the user can complete the SSPR process. At the end of the SSPR process, the locally cached credentials must be updated, so the user can sign into his laptop when he takes it off-line again Hitachi ID Systems, Inc. All rights reserved. 9

13 5 Multi-Factor Authentication: Smart Cards and Tokens Passwords and in particular password management practices are often insecure. To improve system security, many organizations are turning to multi-factor authentication technologies such as the following: Table 5. Multi-Factor Authentication Options Technology Description Examples Support issues One time password Smart card Users are provisioned a physical card or token, which displays a new pseudo-random number every minute. To authenticate, users type both the currently-displayed pseudo-random number and a PIN which they must remember. Authentication works only for network-attached PCs. Users are provisioned a card with an on-board CPU and memory chip, that contains their public key certificate. User PCs are equipped with a smart card reader and the organization deploys a card management system and a PKI infrastructure. To authenticate, users insert their card into their PC. Authentication works both for network-attached and offline PCs. RSA SecurID, Vasco Digipass ActivCard, Gemalto, Aladdin, RSA Lost/stolen token. Forgotten PIN. Clock drift. Lost/stolen card. Forgotten PIN. Organizations that deploy these technologies need a way to automate a variety of processes: Process Enrollment Deactivation PIN reset PIN synchronization Table 6. Multi-Factor Authentication: User Support Processes Description Allocating smart cards and tokens to new users and initializing them. Turning off smart cards and tokens associated with departed users. Set a new PIN if the user forgot its current value. Synchronize the PIN with other PINs or passwords, so there is less for each user to remember Hitachi ID Systems, Inc. All rights reserved. 10

14 Process Emergency passcodes Clock synchronization Table 6. Multi-Factor Authentication: User Support Processes Description Used to authenticate users who misplaced their token or smart card, but are confident that it has not been stolen or permanently lost. Reactivate a one time password (OTP) whose clock has drifted so far apart from the server s clock that it can no longer authenticate. Smart card PIN resets raise particular technical challenges: Challenge Local code Multiple integrations Locked out users Mobile users Table 7. Technical Challenges for Smart Card PIN Reset Description A new PIN can only be written to a smart card by the PC to which it is connected. This means that a PIN reset can only be performed locally on the user s workstation, not remotely. In practice, this means that the user must access a self-service PIN reset portal and - after suitable authentication - invoke an ActiveX component which will run on his PC and reset the PIN on the smart card attached to his card reader. A solution without client software is not possible, short of the user physically visiting an IT support desk. Smart card systems have multiple moving parts: 1. An inventory of physical cards, provisioned to users. These may be of different types, from different manufacturers. 2. Card readers attached to user PCs. Again - multiple models and vendors are possible. 3. A card management system, used to initialize cards. 4. A public key infrastructure (PKI) used to issue and revoke personal cryptographic certificates. Automation typically integrates with most or all of these components. Users typically sign into their PC with a smart card. That means that the same problem and solution alternatives described in item 1 on Page 8 and Appendix A on Page 25, respectively, apply. Users may be away from the corporate network when they need a smart card PIN reset. The same problems and solutions raised in item 3 on Page 8 apply Hitachi ID Systems, Inc. All rights reserved. 11

15 6 Public Key Infrastructure and Encrypted Key Files Some organizations have deployed public key infrastructures either instead of or alongside more traditional password-based authentication schemes. There are several types of this technology in use today: 1. X.509 based certificates issued from a specialized certificate authority product, such as Entrust or Verisign. 2. X.509 based certificates issued from a Microsoft Active Directory infrastructure (with the CA built into the Windows server OS). 3. Either of the above, in conjunction with smart cards as the primary storage location for personal certificate files. 4. Lotus Notes ID files which are not based on the X.509 standard but can contain X.509 certificates as well as Notes-specific key material. Other types of public key encryption, such as PGP and SSH, use a web of trust model and are beyond the scope of this document. In general, PKI systems require that each user has a pair of keys / certificates: 1. A private key, to which only the legitimate user has access. 2. A public key, which is well publicized and which is signed by a certificate authority as a mechanism that assures all users of the key s authenticity. Each user s private key is: 1. Usually encrypted, usually with a password servicing as the encryption key. 2. Almost always stored locally on the user s computer. 3. Often stored in multiple places (i.e., multiple copies exist). This encryption of each user s private key creates both business and technical password management challenges: Challenge Weak passwords Forgotten passwords Table 8. Support and Security Challenges in Public Key Infrastructures Description The security of the entire PKI system rests on how well users private keys are protected. If users encrypt their private keys with weak passwords, then the PKI system will be vulnerable to password guessing attacks. Users will forget the password used to open their private key just as they will forget any other password. A process is required to authenticate these users and help them get back to work Hitachi ID Systems, Inc. All rights reserved. 12

16 Challenge No password reset function Table 8. Support and Security Challenges in Public Key Infrastructures Description Since a user s private key is encrypted and the encryption key is related to a user s password, loss of the password means loss of the key, which in turn means that the private key cannot be opened. An administrative password reset function is not possible in this architecture. A mechanism is required to assist users who forget their passwords. Possibilities include: 1. Issue a new credential i.e., a forgotten password degenerates into a user-deactivation plus a user-creation. This is undesirable since any documents encrypted with the old private key will be irretrievably lost. 2. Use two passwords to encrypt every private key one for the user and a backup password for administrators. This can be hard to manage, especially when the contents of the key file change. 3. Keep a backup database of all private keys and the passwords that unlock each key. Use this to recover lost passwords and re-encrypt keys with new ones. Key delivery infrastructure Regardless of which simulated password reset mechanism above is used, new keys must be delivered to user PCs once issued. This is complicated by the fact that users may have multiple copies of their private key file. These problems are serious issues for the 140 million or so users of Lotus Notes world-wide. Password resets for PKI users (which in practice are mostly Lotus Notes users) are time consuming, expensive for the IT support group and frustrating for users. To effectively manage PKI certificates and in particular to automate management of the passwords used to unlock private key files, a password management system must: 1. Include a key repository, where private keys and passwords are securely stored. 2. Include infrastructure to construct and update the aforementioned key repository. 3. Include a mechanism to simulate password resets, by: (a) Fetching an appropriate key from the repository. (b) Unlocking the key file with the password in the repository. (c) Re-encrypting the key file with a new password. (d) Putting both the updated key file and new password back in the repository. 4. Include infrastructure to deliver updated key files to user PCs and (multiple) other locations where users keep their keys Hitachi ID Systems, Inc. All rights reserved. 13

17 7 Full Disk Encryption Organizations are subject to ever more stringent rules regarding the protection of personally identifying data about employees, customers, patients and more. Since one of the most common ways in which data can be compromised is through physical theft of a computer or storage media containing sensitive data, many organizations are turning to full disk encryption as a way to limit the damage caused by loss or theft of hardware. If full disk encryption is used, even if a PC or USB drive is stolen, data on the stolen PC or drive remains safe. Full disk encryption programs typically work as follows: Process PC power up Optional: unified login Optional: synchronized passwords Table 9. Process Overview for Full Disk Encryption Description Disk encryption software starts up from boot sector. User is prompted for a password. User types a password. The user-entered password is used to decrypt the HDD encryption key (which was randomly generated when the encryption software was first installed). A cryptographic key is derived from the password. Further disk blocks are decrypted using this key. The OS boots from those disk blocks. The OS hard disk device driver is wrapped or replaced by one associated with the encryption software, which decrypts blocks read from disk and encrypts blocks written to disk on behalf of the OS. The password entered by the user in 9 is offered to the OS, so that (if it matches the OS login password) the user does not have to type it again to sign into the OS. If an OS password change is detected, it is used to re-encrypt the disk encryption key. This process creates both business and technical challenges: Challenge Weak passwords Forgotten passwords Table 10. Security and Support Challenges for Full Disk Encryption Description The security of the filesystem rests on the security of user passwords. If a user chooses an easily guessed password, the filesystem may be compromised if the device is stolen or even if the device is temporarily outside the user s control. Users will forget the password used to gain access to their hard disks. A process is required to authenticate these users and help them get back to work Hitachi ID Systems, Inc. All rights reserved. 14

18 Challenge Complicated key recovery process Table 10. Security and Support Challenges for Full Disk Encryption Description There is no way to perform a simple network-based password reset process the OS has not yet started up, so there is normally no network stack running on the user s PC when key recovery is needed. This means that a backup password must be made available to the user, with which he can activate his hard disk and start his OS. As more organizations deploy full disk encryption as a robust defense against data leakage, the cost of supporting users who forgot their password increases rapidly. A self-service solution for key management is needed to keep the cost of this support process under control. To effectively manage hard disk encryption keys and in particular to automate the key recovery process for users who forgot their "boot up password," a password management system must: 1. Be available before the user s PC operating system has started up. In practical terms, this means either: (a) A dual-boot mechanism: i. installed on a second partition on the user s PC, or ii. booting from a USB drive physically provisioned to each user. (b) A solution accessed from a hand-held device: i. telephone land line or cell phone, or ii. web browser on a smart phone. 2. Be able to mediate the key recovery process between the hard disk encryption software on the user s PC and the key recovery server. In general, key recovery works as illustrated in Figure 3. HDD Crypto Software 1 Key recovery challenge (A) 2 Authenticate Password Management Server 4 Forward challenge (A) HDD Key Escrow Server 3 Forward challenge (A) 7 Key in response (B) 6 Forward response (B) 5 Response (B) User Phone or Mobile Browser Figure 3: Key recovery chain of communication self-service In this process, the user acts as an intermediary between the hard disk encryption software on his PC and the password management system. While this is less than ideal, it is preferable to the assisted service model, where two users are in the communication path, as shown in Figure Hitachi ID Systems, Inc. All rights reserved. 15

19 HDD Crypto Software 2 Key recovery challenge (A) 1 Authenticate 4 Forward challenge (A) HDD Key Escrow Server 7 Key in response (B) 3 Forward challenge (A) 6 Forward response (B) 5 Forward response (B) User Phone Phone IT Help Desk Technician Figure 4: Key recovery chain of communication assisted service 2010 Hitachi ID Systems, Inc. All rights reserved. 16

20 8 User Enrollment and Adoption A system for self-service management of passwords, tokens, smart cards and encryption keys can yield cost savings by reducing the incidence of technical support incidents and by moving resolution of those incidents out of the help desk, to a self-service model. Self-service depends on user adoption if users don t use it, cost savings at the help desk will simply not materialize. User adoption, in turn, depends on: 1. User awareness users won t use it if they don t know about it. 2. Ease of use users won t use it if it s too hard to use. 3. Enrollment users won t use functions such as password reset when they have a login problem if they cannot authenticate, which in turn may be because they failed to previously complete their profile of security questions. 8.1 User awareness Users will not remember to use a system unless it s presented as an option to them at the time they need it. This is best illustrated with some examples: Process Self-service password reset Password synchronization Smart card PIN reset OTP Token PIN reset Table 11. Optimal User Interface Placement to Maximize User Awareness Where the process needs to be visible At the system or application login prompt. For example, a reset forgotten password button at the Windows login screen. Either in the system or application login process, where a user is forced to change passwords, or through a less forceful reminder (e.g., ) sent to the user before his password actually expires. At the workstation login prompt, as this is typically where users realize that they forgot their smart card PIN. On the help desk telephone system, as OTP tokens are most often used by mobile workers to establish a VPN connection to the network, so these users are likely to be disconnected from the network when they realize they need a new PIN and will consequently call the help desk. 8.2 User enrollment A password management system may employ several types of enrollment: 2010 Hitachi ID Systems, Inc. All rights reserved. 17

21 Type of data Login IDs Security questions Biometric samples Demographic information Table 12. Types of Data Which May Require User Enrollment Description The system needs to know what login ID each user has on each system and application and this information may (among other mechanisms) be collected from users themselves. The system may authenticate users who forgot their password or PIN by asking them to answer a series of security questions. Answers to these questions, and in some cases the questions themselves, may be the product of a user enrollment process. The system may authenticate users who forgot their password or PIN by asking them to provide a biometric sample such as a voice print. This also needs to be collected from users before it can be used. Information such as each user s mobile phone number may be collected, either for general utility outside the password management system (e.g., emergency contact information) or as an authentication factor (e.g., send a random PIN to the user s mobile using SMS). User enrollment is more complex than it might first appear. For example, sending out a single bulk asking users to complete their profile is likely to result in most users pressing the Delete button and nothing more. Effective user enrollment should be automated and should be built right into the password management system. Some import capabilities of an enrollment system include: Feature Automatic invitations Strong authentication Throttled invitations Throttled reminders Table 13. Technical Features of a Robust User Enrollment Management System Description The system should be able to automatically identify all users who need to perform one or more enrollment steps and to automatically invite them to do so. For example, it might be linked to Active Directory, inviting users whose login accounts are not disabled to act. Before users enroll, they should be authenticated. The process they use to authenticate at enrollment time should be at least as strong as the passwords, smart cards and other technologies which the system will help users to manage. For example, authenticating with a strong password or token passcode is acceptable, while authenticating with an ed PIN is not. Some subset of the users invited to complete their profiles will inevitably call the help desk asking for an explanation, verifying that the invitation is legitimate, etc. If just 5% of all users do this, and every user tries to enroll on the same day, then the help desk will be overwhelmed with calls. To avoid this, it makes sense to throttle the rate at which invitations are sent out say to 500 or 1000 per day, so as to limit the number of net-new help desk calls that the enrollment process itself triggers. Just as a limit should be set on the number of invitations sent per day, it also makes sense to limit the frequency with which any given user is asked to enroll. A user who is nagged daily is more likely to become annoyed than compliant Hitachi ID Systems, Inc. All rights reserved. 18

22 Feature Integrated process Personalized Auto-start Forced enrollment Table 13. Technical Features of a Robust User Enrollment Management System Description Enrollment of different types of data (e.g., security questions, biometrics, etc.) should be linked. Users should not be asked in one message to use one process to fill in one type of data and later asked in another message to use another process to fill in another part of their profile. The simplest enrollment system should send personalized s to users, with a link they can follow to complete their profile. This is relatively simple and unobtrusive, but may be ignored by many users. A somewhat more aggressive form of enrollment is to run a program whenever a user logs onto the network to check whether the user needs to complete any enrollment steps and if so automatically launch a web browser to the appropriate URL. This is a somewhat more aggressive form of enrollment, though still easy to bypass (just close the browser). A more aggressive form of enrollment is to launch a kiosk-mode web browser when the user signs onto the network. In this case, the user cannot do anything other than enroll. Only when enrollment is complete will the user be allowed to access his desktop. Clearly, this approach requires an executive mandate Hitachi ID Systems, Inc. All rights reserved. 19

23 9 Privileged Accounts and Passwords In addition to login accounts used by regular users, most systems also have special login accounts used by administrators to manage the system, or used to run service programs or used by one application to connect to another. These accounts are considered to be privileged, in the sense that they have access to more data and more system functions than normal user accounts. Privileged accounts, if misused, can cause far more harm to an organization than regular user accounts. Privileged accounts generally depend on passwords: Account type Administrator accounts Service accounts Embedded accounts Table 14. Types of Privileged Accounts and Why They Use Passwords Reasons that only a password can be used Need to be functional when a computer is offline, which rules out OTP tokens. They also need to be functional when a smart card reader is not plugged in or functional, which usually disqualifies smart cards as well. A computer cannot plug in a smart card or read the code on an OTP token to authenticate when starting the service. Used by one application to connect to another - must use passwords because other authentication factors are not accessible to an unattended computer program. In many organizations, privileged passwords are actually managed less securely than regular passwords: Common practice Shared accounts Written passwords Unexpiring passwords Table 15. Security Vulnerabilities Associated With Privileged Accounts Description Privileged accounts are often shared. This is more reasonable than might first appear. Consider a small team of ten administrators who must manage 1000 Windows servers. It s much easier to create 1000 local administrator accounts than 10,000. Rather than have the same password on every device where a given administrator account is used, it makes sense to assign a unique password to each device and share access to the list of these passwords. Privileged accounts typically have non-expiring passwords. In part this is because coordinating password changes among multiple administrators, service programs, applications, etc. is difficult and error prone, so often avoided. Security problems created When team members leave, it can be very difficult to deactivate their access, because it spans so many devices. The security of hundreds of assets may be reduced to the security of a piece of paper (or spreadsheet, etc.). This can seriously compromise network security. An attacker may have an unlimited amount of time to try to compromise a privileged account s password, thereby significantly increasing his chances of success Hitachi ID Systems, Inc. All rights reserved. 20

24 It makes sense to manage privileged accounts with as much care and automation as is taken with user passwords. This can mean: Table 16. Technical Characteristics of a Robust System for Managing Privileged Passwords Feature Randomizing passwords Encrypted storage Replicated storage Controlled disclosure Strong authentication Role based access control Audit logs and reports Autodiscovery Auto-launched sessions Service integration Embedded password support Description Set the password on every privileged account on every system to a new, unique, random value on a regular schedule (e.g., daily). This eliminates the risks posed by shared, written or non-expiring passwords. Store random passwords in an encrypted database, to reduce the risk of catastrophic disclosure. Replicate the storage of randomized passwords between at least two servers, installed in at least two physically distinct sites, to reduce the risk of catastrophic data loss (e.g., due to a disaster at one site). Control who (administrators) and what (services and applications) can gain access to a given privileged account using static rules and dynamic workflow approval processes. Support robust authentication of administrators and programs before allowing them access to privileged accounts. For example, administrators may be required to use smart cards or tokens, while programs may use one-time keys, replaced at every successful login. Use roles to efficiently manage the rights assigned to people and programs. Record every attempted and completed access disclosure, to create accountability regarding the use of privileged accounts. Extract lists of computers from sources such as a directory or an asset management system. Extract lists of privileged accounts by interrogating every computer. Automatically classify computers and accounts, so as to automatically manage privileged passwords. Rather than displaying passwords to administrators, automatically launch administrative login sessions (RDP, SSH, SQL Studio, etc.) on their behalf. Notify Windows OS components such as Service Control Manager, Scheduler and IIS of new passwords once they are set, to ensure service continuity after service account password changes. Enable applications to authenticate themselves and request embedded passwords, in order to eliminate passwords stored as plaintext in configuration files and program binaries Hitachi ID Systems, Inc. All rights reserved. 21

25 10 The Future Some authentication management processes are relatively new or emerging but, nonetheless, should be considered in the context of a long-term system investment. One example is federation. Users should be able to sign into a shared platform and from there launch sessions - without extra login prompts - into federated systems and applications. For example, a user might sign into a corporate password management system and follow a link to SalesForce.com or an HR benefits system, either of which may reside outside the corporate firewall. Another example is user-to-user authentication. In some organizations, there are cases where one user needs to validate the identity of another user prior to providing a business service. For example, a funds transfer desk in a bank may need to authenticate an investment adviser on the phone before helping him move money from one account to another. This might be aided by a corporate password management system, where a web UI is exposed that helps users authenticate one another, even if they have never met and don t know one another Hitachi ID Systems, Inc. All rights reserved. 22

26 11 Summary Password management has grown from simple self-service password reset to a complex, enterprise-scale platform for supporting: 1. Password reset, from a desktop login screen, web UI or telephone. 2. PIN reset for smart cards and OTP tokens. 3. Enrollment of user profile data, such as security questions, login IDs, biometrics or demographics. 4. Key recovery for encrypted hard disk software. 5. Password synchronization and reset for the passwords that protect private keys in a public key infrastructure. 6. Management of privileged passwords for administrators, service accounts and embedded accounts. These changes have been in response to a changing landscape of business requirements and technical infrastructure: 1. Users are increasingly mobile. 2. Acceptable downtime is continuously shrinking. 3. The need for security is continuously increasing. 4. Technologies including smart cards, OTP tokens, full disk encryption and PKI are being deployed in more and more organizations. Future growth in the field of password management may include federated authentication and mutual authentication of business users. Organizations considering tactical solutions, such as SSPR for AD, should consider a more robust solution instead. What other authentication technologies require support automation? What other integrations would add value? As product capabilities have evolved, what started as simple password reset has grown into enterprise-scale authentication management. Organizations should consider what their authentication management platform should look like in the future and invest in products today that can meet the full spectrum of current needs and grow to fill future needs Hitachi ID Systems, Inc. All rights reserved. 23

27 APPENDICES 2010 Hitachi ID Systems, Inc. All rights reserved. 24

28 A Self-service password reset for locked out users Users often forget their initial network login password or inadvertently trigger an intruder lockout. These users should be able to get assistance, reset their network or local password, clear intruder lockouts and get back to work. Since these users have a problem with their workstation login, they cannot access a conventional web browser or client/server application with which to resolve their problem. The problem these users face is how to get to a user interface, so that they can fix their login problem and subsequently access their own workstation desktop. This problem is especially acute for mobile users, who use cached domain passwords to sign into their workstation and who may not be attached to the corporate network when they experience a forgotten password problem. When users forget or lock out their primary password, they are in a Catch-22 situation: they cannot log into their computer and open a web browser but cannot open a web browser to fix their password and make it possible to log in. Hitachi ID Password Manager includes a variety of mechanisms to address the problem of locked out users. Each of these approaches has its own strengths and weaknesses, as described below: Option Pros Cons 1 Do nothing: users continue to call the help desk. Inexpensive, nothing to deploy. The help desk continues to field a high password reset call volume. No solution for local passwords or mobile users. 2 Ask a neighbor: Use someone else s web browser to access self-service password reset. Inexpensive, no client software to deploy. Users may be working alone or at odd hours. No solution for local passwords or mobile users. Wastes time for two users, rather than one. May violate a security policy in some organizations Hitachi ID Systems, Inc. All rights reserved. 25

29 Option Pros Cons 3 Secure kiosk account (SKA): Sign into any PC with a generic ID such as help and no password. This launches a kiosk-mode web browser directed to the password reset web page. Simple, inexpensive deployment, with no client software component. Users can reset both local and network passwords. Introduces a generic account on the network, which may violate policy, no matter how well it is locked down. One user can trigger a lockout on the help account, denying service to other users who require a password reset. Does not help mobile users. 4 Personalized SKA: Same as the domain-wide SKA above, but the universal help account is replaced with one personal account per user. For example, each user s help account could have their employee number for a login ID and a combination of their SSN and date of birth for a password. 5 Local SKA: Same as the domain-wide SKA above, but the help account is created on each computer, rather than on the domain. 6 Telephone password reset: Users call an automated system, identify themselves using touch-tone input of a numeric identifier, authenticate with touch-tone input of answers to security questions or with voice print biometrics and select a new password. Eliminates the guest account on the domain, which does not have a password. Eliminates the guest account on the domain. Can be configured to assist mobile users who forgot their cached domain password (by automatically establishing a temporary VPN connection). Simple deployment of centralized infrastructure. No client software impact. May leverage an existing IVR (interactive voice response) system. Helpful for remote users who need assistance connecting to the corporate VPN. Requires creation of thousands of additional domain accounts. Requires ongoing creation and deletion of domain accounts. These new accounts are special their passwords do not expire and would likely not meet strength rules. Requires a small footprint on each computer (the local help account. New physical infrastructure is usually required. Users generally don t like to talk to a machine so adoption rates are lower than with a web UI. Does not help mobile users who forgot their cached domain password. Does not help unlock PINs on smart cards Hitachi ID Systems, Inc. All rights reserved. 26

30 Option Pros Cons 8 Physical kiosks: Deploy physical Intranet kiosks at each office location. Eliminates generic or guest accounts. May be used by multiple applications that are suitable for physically-present but unauthenticated users (e.g., phone directory lookup, badge management, etc.). Costly to deploy hardware at many locations. Does not help mobile users who forgot their cached domain password. Users may prefer to call the help desk, rather than walking over to a physical kiosk. 9 GINA DLL: Windows XP: Install a GINA DLL on user computers, which adds a reset my password button to the login screen. 10 GINA Extension Service: Similar to the GINA DLL, but uses a sophisticated service infrastructure to modify the UI of the native GINA, rather than installing a GINA DLL. 11 Credential Provider: The equivalent of a GINA DLL, but for the login infrastructure on Windows 7 and Windows Vista. User friendly, intuitive access to self-service. Can be configured to assist mobile users who forgot their cached domain password (by automatically establishing a temporary VPN connection). Works on Windows Terminal Server and Citrix Presentation Manager. User friendly, intuitive access to self-service. Can be configured to assist mobile users who forgot their cached domain password (by automatically establishing a temporary VPN connection). More robust, fault-tolerant installation process than the GINA DLL. User friendly, intuitive access to self-service. Can be configured to assist mobile users who forgot their cached domain password (by automatically establishing a temporary VPN connection). Works on Windows Terminal Server and Citrix Presentation Manager. More robust infrastructure than GINA DLLs on Windows XP. Requires intrusive software to be installed on every computer. Broken installation or out-of-order uninstallation will render the computer inoperable (i.e., brick the PC ). Requires software to be installed on every computer. Does not work on Citrix Presentation Server or Windows Terminal Server only works on personal computers. Deployment of intrusive software to every workstation. 500, Street SE, Calgary AB Canada T2G 2J3 Tel: Fax: [email protected] File: /pub/wp/documents/from-sspr-to-auth-mgmt/from-sspr-to-authentication-mana Date:

31 500, Street SE, Calgary AB Canada T2G 2J3 Tel: Fax: File: /pub/wp/documents/from-sspr-to-auth-mgmt/from-sspr-to-authentication-mana Date: