From Password Reset to Authentication Management
Upcoming SlideShare
Loading in...5
×
 

From Password Reset to Authentication Management

on

  • 1,788 views

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

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 long-term needs.

Sections:

- In the Beginning: A Simple Problem
- Proliferation of Passwords
- Locked-out Users, Mobile Users and Cached Passwords
- Multi-Factor Authentication: Smart Cards and Tokens
- Public Key Infrastructure and Encrypted Key Files
- Full Disk Encryption
- User Enrollment and Adoption
- Privileged Accounts and Passwords
- The Future

Statistics

Views

Total Views
1,788
Slideshare-icon Views on SlideShare
1,787
Embed Views
1

Actions

Likes
0
Downloads
42
Comments
0

1 Embed 1

http://www.pinterest.com 1

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

    From Password Reset to Authentication Management From Password Reset to Authentication Management Document Transcript

    • From Password Reset to Authentication Management: the Evolution of Password Management Technology © 2014 Hitachi ID Systems, Inc. All rights reserved.
    • Contents 1 Introduction 1 2 In the Beginning: A Simple Problem 2 3 Proliferation of Passwords 3 3.1 Trend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Impact on SSPR infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 Password synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 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 17 8.1 User awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2 User enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9 Privileged Accounts and Passwords 20 10 The Future 22 11 Summary 23 APPENDICES 24 A Self-service password reset for locked out users 25 i
    • List of Tables 1. Self-Service Password Reset Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Password Management Challenges due to Heterogeneous Systems . . . . . . . . . . . . . . . . 4 3. Technical Challenges for Password Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Complications to Self-Service Password Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Multi-Factor Authentication Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Multi-Factor Authentication: User Support Processes . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Multi-Factor Authentication: User Support Processes . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Technical Challenges for Smart Card PIN Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Support and Security Challenges in Public Key Infrastructures . . . . . . . . . . . . . . . . . . . 12 8. Support and Security Challenges in Public Key Infrastructures . . . . . . . . . . . . . . . . . . . 13 9. Process Overview for Full Disk Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security and Support Challenges for Full Disk Encryption . . . . . . . . . . . . . . . . . . . . . 14 10. Security and Support Challenges for Full Disk Encryption . . . . . . . . . . . . . . . . . . . . . 15 11. Optimal User Interface Placement to Maximize User Awareness . . . . . . . . . . . . . . . . . 17 12. Types of Data Which May Require User Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 18 13. Technical Features of a Robust User Enrollment Management System . . . . . . . . . . . . . . 18 13. Technical Features of a Robust User Enrollment Management System . . . . . . . . . . . . . . 19 14. Types of Privileged Accounts and Why They Use Passwords . . . . . . . . . . . . . . . . . . . 20 15. Security Vulnerabilities Associated With Privileged Accounts . . . . . . . . . . . . . . . . . . . 20 16. Technical Characteristics of a Robust System for Managing Privileged Passwords . . . . . . . 21 ii
    • From Password Reset to Authentication Management 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 organiza- tions 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 long- term needs. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 1
    • From Password Reset to Authentication Management 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: Table 1. Self-Service Password Reset Overview Business challenge: 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. Security exposure: 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. Root cause analysis: 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. Solution: 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. More detail: 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. Solution benefit: 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 2
    • From Password Reset to Authentication Management 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: 1980 1990 2000 2010 10 20 30 Mainframe LAN Client/Server Intranet ActiveDirectory, WebSSO Multi-factor, PKI, HDDEncryption 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 3
    • From Password Reset to Authentication Management 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: 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. 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. Multiple policies: 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. Must support a mix of password policies, to help users choose passwords that will actually work on selected systems. Different login IDs: Users may have different login IDs on different systems and applications. 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: © 2014 Hitachi ID Systems, Inc.. All rights reserved. 4
    • From Password Reset to Authentication Management Table 3. Technical Challenges for Password Synchronization Challenge Details Impact on password synch. system Different password hashes 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. 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. Peak load 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. 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. Feedback 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. 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 = 40. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 5
    • From Password Reset to Authentication Management Load Balancer Password Management Server 2 Password Management Server 1 System B System A Trigger code Trigger code 1 User changes password 2 Trigger PW synch 3 Trigger sent to a random PW mgmt server 4 Set same password on another app 6 Trigger sent to a random server 5 Trigger PW synch (again) 8 Trigger feedback 7 Set same password on another app Figure 2: Password synchronization feedback 2. PT = minimum number of password changes per year for all users = 10, 000 × 40 = 400,000. 3. 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 6
    • From Password Reset to Authentication Management 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 7
    • From Password Reset to Authentication Management 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 Windows- hosted 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: © 2014 Hitachi ID Systems, Inc.. All rights reserved. 8
    • From Password Reset to Authentication Management Table 4. Complications to Self-Service Password Reset Challenge Required capability Locked out users: 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 Section A on Page 25 – each of which represents its own, unique compromise between security, usability and deployment complexity. Cached passwords: 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. Mobile users: 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 9
    • From Password Reset to Authentication Management 5 Multi-Factor Authentication: Smart Cards and Tokens Passwords and in particular password management practices are often insecure. To improve system secu- rity, 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 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. RSA SecurID, Vasco Digipass • Lost/stolen token. • Forgotten PIN. • Clock drift. Smart card 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. ActivCard, Gemalto, Aladdin, RSA • Lost/stolen card. • Forgotten PIN. Organizations that deploy these technologies need a way to automate a variety of processes: Table 6. Multi-Factor Authentication: User Support Processes Process Description Enrollment Allocating smart cards and tokens to new users and initializing them. Deactivation Turning off smart cards and tokens associated with departed users. PIN reset Set a new PIN if the user forgot its current value. PIN synchro- nization Synchronize the PIN with other PINs or passwords, so there is less for each user to remember. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 10
    • From Password Reset to Authentication Management Table 6. Multi-Factor Authentication: User Support Processes Process Description Emergency passcodes Used to authenticate users who misplaced their token or smart card, but are confident that it has not been stolen or permanently lost. Clock synchro- nization 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: Table 7. Technical Challenges for Smart Card PIN Reset Challenge Description Local code 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. Multiple integrations 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. Locked out users 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 Section A on Page 25, respectively, apply. Mobile users 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 11
    • From Password Reset to Authentication Management 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: Table 8. Support and Security Challenges in Public Key Infrastructures Challenge Description Weak passwords 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. Forgotten passwords 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 12
    • From Password Reset to Authentication Management Table 8. Support and Security Challenges in Public Key Infrastructures Challenge Description No password reset function 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 13
    • From Password Reset to Authentication Management 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: Table 9. Process Overview for Full Disk Encryption Process Description PC power up • 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. Optional: unified login 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. Optional: synchronized passwords 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: Table 10. Security and Support Challenges for Full Disk Encryption Challenge Description Weak passwords 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. Forgotten passwords 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 14
    • From Password Reset to Authentication Management Table 10. Security and Support Challenges for Full Disk Encryption Challenge Description Complicated key recovery process 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 Key Escrow Server Password Management Server HDD Crypto Software 1 Key recovery challenge (A) 4 Forward challenge (A) 7 Key in response (B) 5 Response (B)6 Forward response (B) 3 Forward challenge (A) 2 Authenticate 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 4. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 15
    • From Password Reset to Authentication Management HDD Key Escrow Server HDD Crypto Software 2 Key recovery challenge (A) 7 Key in response (B) 4 Forward challenge (A) 5 Forward response (B) User IT Help Desk TechnicianPhone Phone 6 Forward response (B) 3 Forward challenge (A) 1 Authenticate Figure 4: Key recovery chain of communication – assisted service © 2014 Hitachi ID Systems, Inc.. All rights reserved. 16
    • From Password Reset to Authentication Management 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: Table 11. Optimal User Interface Placement to Maximize User Awareness Process Where the process needs to be visible Self-service password reset At the system or application login prompt. For example, a “reset forgotten password” button at the Windows login screen. Password syn- chronization Either in the system or application login process, where a user is forced to change passwords, or through a less forceful reminder (e.g., e-mail) sent to the user before his password actually expires. Smart card PIN reset At the workstation login prompt, as this is typically where users realize that they forgot their smart card PIN. OTP Token PIN reset 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: © 2014 Hitachi ID Systems, Inc.. All rights reserved. 17
    • From Password Reset to Authentication Management Table 12. Types of Data Which May Require User Enrollment Type of data Description Login IDs 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. Security questions 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. Biometric samples 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. Demographic information 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 e-mail 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: Table 13. Technical Features of a Robust User Enrollment Management System Feature Description Automatic invitations 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. Strong authentication 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 e-mailed PIN is not. Throttled invitations 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. Throttled reminders 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 18
    • From Password Reset to Authentication Management Table 13. Technical Features of a Robust User Enrollment Management System Feature Description Integrated process 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. Personalized e-mail The simplest enrollment system should send personalized e-mails 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. Auto-start 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). Forced enrollment 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 19
    • From Password Reset to Authentication Management 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: Table 14. Types of Privileged Accounts and Why They Use Passwords Account type Reasons that only a password can be used Administrator accounts 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. Service accounts A computer cannot plug in a smart card or read the code on an OTP token to authenticate when starting the service. Embedded accounts 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: Table 15. Security Vulnerabilities Associated With Privileged Accounts Common practice Description Security problems created Shared accounts 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. When team members leave, it can be very difficult to deactivate their access, because it spans so many devices. Written passwords 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. 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. Unexpiring 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. 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 20
    • From Password Reset to Authentication Management 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 Description Randomizing passwords 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. Encrypted storage Store random passwords in an encrypted database, to reduce the risk of catastrophic disclosure. Replicated storage 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). Controlled disclosure Control who (administrators) and what (services and applications) can gain access to a given privileged account using static rules and dynamic workflow approval processes. Strong authentication 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. Role based access control Use roles to efficiently manage the rights assigned to people and programs. Audit logs and reports Record every attempted and completed access disclosure, to create accountability regarding the use of privileged accounts. Auto- discovery 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. Auto-launched sessions Rather than displaying passwords to administrators, automatically launch administrative login sessions (RDP, SSH, SQL Studio, etc.) on their behalf. Service integration 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. Embedded password support Enable applications to authenticate themselves and request embedded passwords, in order to eliminate passwords stored as plaintext in configuration files and program binaries. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 21
    • From Password Reset to Authentication Management 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 22
    • From Password Reset to Authentication Management 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 infras- tructure. 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 au- thentication 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 23
    • From Password Reset to Authentication Management APPENDICES © 2014 Hitachi ID Systems, Inc.. All rights reserved. 24
    • From Password Reset to Authentication Management 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 their primary password or trigger an intruder lockout, 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 users locked out of their PC login screen. 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 25
    • From Password Reset to Authentication Management 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 an intruder 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. • Eliminates the “guest” account on the domain, which does not have a password. • 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. 5 Local SKA: Same as the domain-wide SKA above, but the “help” account is created on each computer, rather than on the domain. • 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). • Requires a small footprint on each computer (the local “help” account.) 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. • 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. • 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 portal. • Does not help mobile users who forgot their cached domain password. • Does not help unlock PINs on smart cards. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 26
    • From Password Reset to Authentication Management 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. • 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. • Requires intrusive software to be installed on every computer. • Broken installation or out-of-order un-installation will render the computer inoperable (i.e., “brick the PC”). 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. • 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. • Requires software to be installed on every computer. • Does not work on Citrix Presentation Server or Windows Terminal Server – only works on personal computers. 11 Credential Provider: The equivalent of a GINA DLL, but for the login infrastructure on Windows Vista/7/8. • 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. • Deployment of intrusive software to every workstation. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 27
    • From Password Reset to Authentication Management No other product or vendor supports as many options for assisting users locked out of their PC login screen. 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/from-sspr-to-auth-mgmt/from-sspr-to-authentication-mana Date: 2010-03-25