From Password Reset to Authentication Management

From Password Resetto Authentication Management:

the Evolution of

Password Management Technology

© 2014 Hitachi ID Systems, Inc. All rights reserved.

http://Hitachi-ID.com/

http://Hitachi.com/

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 toreset forgotten passwords to a complex platform for managing multiple authentication factors and encryptionkeys.

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


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

Businesschallenge:

The IT help desk is inundated with calls from users who forgot or locked out theirpassword. This can be as much as 35% of total IT support call volume andreaches a peak during the first morning of each work week.

Securityexposure:

The help desk password reset process is often vulnerable to security exploits. Theanalysts in most help desk organizations can be fooled into resetting passwordsfor an impostor who either sounds too important to challenge or who can correctlyanswer the questions a help desk analyst asks a caller in order to authenticatethat caller.

Root causeanalysis:

Users forget their passwords because: they have too many; they changepasswords right before leaving work for the weekend or a holiday; or passwordcomplexity rules make passwords hard to remember. Users trigger lockouts bytyping old passwords or by failing to notice the state of the Caps Lock or NumLock keys on their keyboards.

Solution: Use a web application where users can authenticate by answering a series ofsecurity questions instead of typing their password. Users can then choose a newpassword without calling the help desk.

More detail: Security questions and answers may not be available for all users, or may beinadequate to the task of reliable authentication. As a result, an enrollment webapplication is also required, where users can authenticate with their password andcomplete their profile with answers to security questions.

Solutionbenefit:

The call volume at a typical IT help desk can be reduced by as much as 25%, solong as the system is effective and the user adoption rate is high.



3 Proliferation of Passwords

3.1 Trend

Most medium to large organizations have a large number of applications, many with their own databases oflogin IDs and passwords.

Some applications can leverage common platforms such as Active Directory to authenticate users, butmany legacy applications cannot. Moreover, some applications which can externalize user authenticationmay 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 towardsseveral passwords per user, rather than just one:

1980 1990 2000 2010

10

20

30

Mai

nfra

me

LAN

Clie

nt/S

erve

r

Intr

anet

Act

ive

Dire

ctor

y,W

eb S

SO

Mul

ti-fa

ctor

,PK

I,H

DD

Enc

rypt

ion

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



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 overcomethree basic challenges:

Table 2. Password Management Challenges due to Heterogeneous Systems

Challenge Details Impact on SSPR system

Heterogeneousplatforms:

In order to continue to provide value, anSSPR system needs to be able to resetpasswords on multiple systems – not justthe Windows environment.

Multiple connectors are needed, eachdedicated to managing passwords on adifferent kind of system. In other words,an AD connector, an LDAP connector,one or more mainframe connectors, oneor more ERP connectors, databaseconnectors, connectors for SaaSapplications, etc.

Multiplepolicies:

Each of the systems where the SSPRsystem will manage passwords mayhave its own password policy, regardinghow often passwords must change andhow they must be composed, so thatthey are hard to guess. Each system willalso have different limitations regardingpassword length and what characterscan be used in a password.

Must support a mix of password policies,to help users choose passwords that willactually work on selected systems.

Different loginIDs:

Users may have different login IDs ondifferent systems and applications.

Must link inconsistent login IDs back totheir (human) owners and their profilesof 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 seemsnatural 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 thenew 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 andreliable, the following challenges must be overcome:



Table 3. Technical Challenges for Password Synchronization

Challenge Details Impact on password synch. system

Differentpasswordhashes

Different systems and applications storepasswords using different cryptographichashing mechanisms. Sincecryptographic hashes are not reversible(i.e., one cannot calculate the plaintextpassword value from the hash valuestored in the password database) andsince hashes are not compatible (thesame plaintext password will yielddifferent hashes on different systems),password synchronization cannot bedone between two systems of differenttypes by simply copying stored passwordvalues from one to another.

To synchronize passwords betweensystems of different types, a plaintextpassword value is required. This isnormally only available at the time apassword is changed. Consequently,password synchronization must beimplemented by capturing newpasswords when they are set.

Peak load Users tend to change their passwordsonly when forced to do so. This normallyhappens when they first sign into theircomputer at the beginning of the workday. Consequently, there is a burst ofpassword changes (and resets, due toforgotten passwords) during the first hourof the first day of the work week. Indeed,up to 50% of all password changes in anentire week tend to happen during thisone hour. This makes passwordsynchronization workloads very bursty –long periods of low activity punctuatedby short periods of very high activity.

A password management system mustscale to handle very high peak workload– up to 100 times more transactions perhour at peak than on average.

Feedback If password synchronization is triggeredby a password change on just onesystem – for example, a native passwordchange on AD or LDAP, or use of thepassword management software’s ownweb UI, then the process is relativelystraightforward. Complexity arises,however, if more than one system isconfigured to trigger passwordsynchronization. When this is the case,a password change can form a feedbackloop, as illustrated in Figure 2.

Since any sort of feedback couldoverload the network, a passwordsynchronization system must eitherforbid multiple triggers (not feasible inmany organizations) or take steps toprevent feedback from happening at all.

Peak password change frequency, mentioned above, bears further scrutiny. Consider an organization with10,000 users, where the average user has 10 login IDs and passwords, and where passwords expire every90 days (i.e., 4 times per year):

1. PU = minimum number of password changes per user per year = 10× 4 = 40.



Load Balancer

Password ManagementServer 2

Password ManagementServer 1

System B

System A

Triggercode

Triggercode

1 User changespassword

2 TriggerPW synch

3 Trigger sent to a random PW mgmt server

4 Set samepassword onanother app 6 Trigger

sent to a randomserver

5 Trigger PW synch(again)

8 Trigger feedback

7 Set samepasswordon anotherapp

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 passwordchanges per hour = 200/2× 40 = 4000/hour =6̃7/minute =1̃/second.

These figures are illustrative only and only take into consideration routine password changes. They ignorehigh volumes of password changes and resets after holidays, for example, which can further amplify peakload.

3.4 Single sign-on

Any discussion of password synchronization inevitably raises a comparison with single sign-on. Why notcontinue to have multiple passwords for every user, but store them somewhere and automatically fill themin? A detailed comparison of password synchronization and single sign-on is beyond the scope of this whitepaper, but some key differences to keep in mind are:

1. Password synchronization does not require software to be installed on every user PC. Eliminating theclient component significantly reduces complexity and, therefore, costs and delays.

2. Password synchronization software does not store user passwords. This eliminates the need for asecure, reliable, distributed database where application credentials are stored.



3. Password synchronization is not specific to a given device or client platform. It works just as well forusers with Windows PCs, Linux, Macs or smart phones.



4 Locked-out Users, Mobile Users and Cached Passwords

Password reset using a web browser user interface is conceptually straightforward, but users often haveproblems 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 thispassword before they can launch a web browser, a pure web-based solution will not help them resetit. In many organizations, 40% or more of password-related support incidents relate to the primarypassword, 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 thispractice, many applications in a typical organization continue to use NTLM-based authentication, sothe password a user typed to sign into his PC will be offered to network services more often thanWindows administrators may realize.

Normally, this behavior is innocuous – it simply eliminates the need for a user to re-authenticate whenhe 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 continueto offer the old, no-longer-valid password to those services. If this happens often enough, the user’sWindows 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 itwith them – home, to an airport, a hotel, for example.

Windows supports mobile users by caching their domain credentials locally (note: this is a persistentcache, unlike the in-memory one described above). Users can sign into their disconnected PC withcached 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 supportprocess is quite complex. In many cases, the user may have to physically bring his PC back to workto resolve the problem, a very expensive and disruptive support incident.

A password management system suitable for enterprise-scale deployment must address each of theseproblems:



Table 4. Complications to Self-Service Password Reset

Challenge Required capability

Locked outusers:

A user interface must be exposed in the login screen of user PCs, so that userscan initiate the self-service password reset process from the login prompt, withoutcompleting a normal login. There are multiple approaches to this problem, asdescribed in Section A on Page 25 – each of which represents its own, uniquecompromise between security, usability and deployment complexity.

Cachedpasswords:

A simple solution to this problem is to ask users to sign off from their PC afterevery password change made through a web browser or over the phone. A moresophisticated and user-friendly solution is to execute an ActiveX component onthe 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 theoffice in order to reset a forgotten password, is to expose a UI element at the loginscreen (as described above) and have it setup a temporary VPN connection tothe corporate network, over which the user can complete the SSPR process. Atthe end of the SSPR process, the locally cached credentials must be updated, sothe user can sign into his laptop when he takes it off-line again.



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 timepassword

Users are provisioned aphysical card or token,which displays a newpseudo-random numberevery minute. Toauthenticate, users typeboth the currently-displayedpseudo-random number anda PIN which they mustremember. Authenticationworks only fornetwork-attached PCs.

RSA SecurID,Vasco Digipass

• Lost/stolen token.• Forgotten PIN.• Clock drift.

Smart card Users are provisioned acard with an on-board CPUand memory chip, thatcontains their public keycertificate. User PCs areequipped with a smart cardreader and the organizationdeploys a card managementsystem and a PKIinfrastructure. Toauthenticate, users inserttheir card into their PC.Authentication works bothfor network-attached andoffline 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 userto remember.



Table 6. Multi-Factor Authentication: User Support Processes

Process Description

Emergencypasscodes

Used to authenticate users who misplaced their token or smart card, but areconfident 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 fromthe 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’sworkstation, not remotely. In practice, this means that the user must access aself-service PIN reset portal and - after suitable authentication - invoke an ActiveXcomponent which will run on his PC and reset the PIN on the smart card attachedto his card reader. A solution without client software is not possible, short of theuser physically visiting an IT support desk.

Multipleintegrations

Smart card systems have multiple moving parts:

1. An inventory of physical cards, provisioned to users. These may be ofdifferent types, from different manufacturers.

2. Card readers attached to user PCs. Again - multiple models and vendorsare 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 outusers

Users typically sign into their PC with a smart card. That means that the sameproblem and solution alternatives described in item 1 on Page 8 and Section A onPage 25, respectively, apply.

Mobile users Users may be away from the corporate network when they need a smart card PINreset. The same problems and solutions raised in item 3 on Page 8 apply.



6 Public Key Infrastructure and Encrypted Key Files

Some organizations have deployed public key infrastructures either instead of or alongside more traditionalpassword-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 orVerisign.

2. X.509 based certificates issued from a Microsoft Active Directory infrastructure (with the CA built intothe Windows server OS).

3. Either of the above, in conjunction with smart cards as the primary storage location for personalcertificate files.

4. Lotus Notes ID files which are not based on the X.509 standard but can contain X.509 certificates aswell 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 thescope 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 mechanismthat 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 managementchallenges:

Table 8. Support and Security Challenges in Public Key Infrastructures


Weakpasswords

The security of the entire PKI system rests on how well users’ private keys areprotected. If users encrypt their private keys with weak passwords, then the PKIsystem will be vulnerable to password guessing attacks.

Forgottenpasswords

Users will forget the password used to open their private key just as they willforget any other password. A process is required to authenticate these users andhelp them get back to work.



Table 8. Support and Security Challenges in Public Key Infrastructures


No passwordreset function

Since a user’s private key is encrypted and the encryption key is related to auser’s password, loss of the password means loss of the key, which in turn meansthat the private key cannot be opened. An administrative password reset functionis not possible in this architecture.

A mechanism is required to assist users who forget their passwords. Possibilitiesinclude:

1. Issue a new credential – i.e., a forgotten password degenerates into auser-deactivation plus a user-creation. This is undesirable since anydocuments encrypted with the old private key will be irretrievably lost.

2. Use two passwords to encrypt every private key – one for the user and abackup password for administrators. This can be hard to manage, especiallywhen the contents of the key file change.

3. Keep a backup database of all private keys and the passwords thatunlock each key. Use this to recover lost passwords and re-encrypt keyswith new ones.

Key deliveryinfrastructure

Regardless of which “simulated” password reset mechanism above is used, newkeys must be delivered to user PCs once issued. This is complicated by the factthat 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. Passwordresets for PKI users (which in practice are mostly Lotus Notes users) are time consuming, expensive for theIT support group and frustrating for users.

To effectively manage PKI certificates and in particular to automate management of the passwords used tounlock 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 whereusers keep their keys.



7 Full Disk Encryption

Organizations are subject to ever more stringent rules regarding the protection of personally identifying dataabout employees, customers, patients and more. Since one of the most common ways in which data canbe compromised is through physical theft of a computer or storage media containing sensitive data, manyorganizations are turning to full disk encryption as a way to limit the damage caused by loss or theft ofhardware.

If full disk encryption is used, even if a PC or USB drive is stolen, data on the stolen PC or drive remainssafe.

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 encryptsblocks 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 matchesthe OS login password) the user does not have to type it again to sign into the OS.

Optional:synchronizedpasswords

If an OS password change is detected, it is used to re-encrypt the disk encryptionkey.

This process creates both business and technical challenges:

Table 10. Security and Support Challenges for Full Disk Encryption


Weakpasswords

The security of the filesystem rests on the security of user passwords. If a userchooses an easily guessed password, the filesystem may be compromised if thedevice is stolen or even if the device is temporarily outside the user’s control.

Forgottenpasswords

Users will forget the password used to gain access to their hard disks. A processis required to authenticate these users and help them get back to work.



Table 10. Security and Support Challenges for Full Disk Encryption


Complicatedkey recoveryprocess

There is no way to perform a simple network-based password reset process – theOS has not yet started up, so there is normally no network stack running on theuser’s PC when key recovery is needed. This means that a backup passwordmust be made available to the user, with which he can activate his hard disk andstart his OS.

As more organizations deploy full disk encryption as a robust defense against data leakage, the cost ofsupporting users who forgot their password increases rapidly. A self-service solution for key managementis 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 forusers 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 meanseither:

(a) A dual-boot mechanism:

i. installed on a second partition on the user’s PC, orii. 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, orii. web browser on a smart phone.

2. Be able to mediate the key recovery process between the hard disk encryption software on the user’sPC and the key recovery server.

In general, key recovery works as illustrated in Figure 3.

HDD KeyEscrowServer

PasswordManagementServer

HDD CryptoSoftware

1 Key recoverychallenge (A)

4 Forwardchallenge (A)

7 Key inresponse (B) 5 Response (B)6 Forward

response (B)


2 Authenticate

User

Phone or MobileBrowser

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 andthe password management system. While this is less than ideal, it is preferable to the assisted servicemodel, where two users are in the communication path, as shown in Figure 4.



HDD KeyEscrowServer

HDD CryptoSoftware

2 Key recoverychallenge (A)

7 Key inresponse (B)


5 Forwardresponse (B)

User

IT HelpDesk

TechnicianPhone Phone

6 Forwardresponse (B)


1 Authenticate

Figure 4: Key recovery chain of communication – assisted service



8 User Enrollment and Adoption

A system for self-service management of passwords, tokens, smart cards and encryption keys can yieldcost savings by reducing the incidence of technical support incidents and by moving resolution of thoseincidents 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 notmaterialize.

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 theycannot authenticate, which in turn may be because they failed to previously complete their profile ofsecurity 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 needit. 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-servicepasswordreset

At the system or application login prompt. For example, a “reset forgottenpassword” button at the Windows login screen.

Password syn-chronization

Either in the system or application login process, where a user is forced to changepasswords, or through a less forceful reminder (e.g., e-mail) sent to the userbefore his password actually expires.

Smart card PINreset

At the workstation login prompt, as this is typically where users realize that theyforgot their smart card PIN.

OTP Token PINreset

On the help desk telephone system, as OTP tokens are most often used bymobile workers to establish a VPN connection to the network, so these users arelikely to be disconnected from the network when they realize they need a new PINand will consequently call the help desk.

8.2 User enrollment

A password management system may employ several types of enrollment:



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 andapplication and this information may (among other mechanisms) be collectedfrom users themselves.

Securityquestions

The system may authenticate users who forgot their password or PIN by askingthem to answer a series of security questions. Answers to these questions, and insome cases the questions themselves, may be the product of a user enrollmentprocess.

Biometricsamples

The system may authenticate users who forgot their password or PIN by askingthem to provide a biometric sample such as a voice print. This also needs to becollected from users before it can be used.

Demographicinformation

Information such as each user’s mobile phone number may be collected, either forgeneral utility outside the password management system (e.g., emergencycontact information) or as an authentication factor (e.g., send a random PIN to theuser’s mobile using SMS).

User enrollment is more complex than it might first appear. For example, sending out a single bulk e-mailasking users to complete their profile is likely to result in most users pressing the “Delete” button – andnothing more.

Effective user enrollment should be automated and should be built right into the password managementsystem. Some import capabilities of an enrollment system include:

Table 13. Technical Features of a Robust User Enrollment Management System

Feature Description

Automaticinvitations

The system should be able to automatically identify all users who need to performone or more enrollment steps and to automatically invite them to do so. Forexample, it might be linked to Active Directory, inviting users whose loginaccounts are not disabled to act.

Strongauthentication

Before users enroll, they should be authenticated. The process they use toauthenticate 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 isacceptable, while authenticating with an e-mailed PIN is not.

Throttledinvitations

Some subset of the users invited to complete their profiles will inevitably call thehelp 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, thenthe help desk will be overwhelmed with calls. To avoid this, it makes sense tothrottle the rate at which invitations are sent out – say to 500 or 1000 per day, soas to limit the number of net-new help desk calls that the enrollment process itselftriggers.

Throttledreminders

Just as a limit should be set on the number of invitations sent per day, it alsomakes sense to limit the frequency with which any given user is asked to enroll. Auser who is nagged daily is more likely to become annoyed than compliant.



Table 13. Technical Features of a Robust User Enrollment Management System

Feature Description

Integratedprocess

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 processto fill in one type of data and later asked in another message to use anotherprocess to fill in another part of their profile.

Personalizede-mail

The simplest enrollment system should send personalized e-mails to users, with alink they can follow to complete their profile. This is relatively simple andunobtrusive, but may be ignored by many users.

Auto-start A somewhat more aggressive form of enrollment is to run a program whenever auser logs onto the network to check whether the user needs to complete anyenrollment steps and – if so – automatically launch a web browser to theappropriate URL. This is a somewhat more aggressive form of enrollment, thoughstill easy to bypass (just close the browser).

Forcedenrollment

A more aggressive form of enrollment is to launch a kiosk-mode web browserwhen the user signs onto the network. In this case, the user cannot do anythingother than enroll. Only when enrollment is complete will the user be allowed toaccess his desktop. Clearly, this approach requires an executive mandate.



9 Privileged Accounts and Passwords

In addition to login accounts used by regular users, most systems also have special login accounts usedby administrators to manage the system, or used to run service programs or used by one application toconnect to another. These accounts are considered to be privileged, in the sense that they have accessto more data and more system functions than normal user accounts. Privileged accounts, if misused, cancause 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

Administratoraccounts

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 orfunctional, which usually disqualifies smart cards as well.

Serviceaccounts

A computer cannot plug in a smart card or read the code on an OTP token toauthenticate when starting the service.

Embeddedaccounts

Used by one application to connect to another - must use passwords becauseother authentication factors are not accessible to an unattended computerprogram.

In many organizations, privileged passwords are actually managed less securely than regular passwords:

Table 15. Security Vulnerabilities Associated With Privileged Accounts

Commonpractice

Description Security problems created

Sharedaccounts

Privileged accounts are often shared.This is more reasonable than might firstappear. Consider a small team of tenadministrators who must manage 1000Windows servers. It’s much easier tocreate 1000 local administrator accountsthan 10,000.

When team members leave, it can bevery difficult to deactivate their access,because it spans so many devices.

Writtenpasswords

Rather than have the same password onevery device where a given administratoraccount is used, it makes sense toassign a unique password to eachdevice and share access to the list ofthese passwords.

The security of hundreds of assets maybe reduced to the security of a piece ofpaper (or spreadsheet, etc.). This canseriously compromise network security.

Unexpiringpasswords

Privileged accounts typically havenon-expiring passwords. In part this isbecause coordinating password changesamong multiple administrators, serviceprograms, applications, etc. is difficultand error prone, so often avoided.

An attacker may have an unlimitedamount of time to try to compromise aprivileged account’s password, therebysignificantly increasing his chances ofsuccess.



It makes sense to manage privileged accounts with as much care and automation as is taken with userpasswords. This can mean:

Table 16. Technical Characteristics of a Robust System for Managing Privileged Passwords

Feature Description

Randomizingpasswords

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 posedby shared, written or non-expiring passwords.

Encryptedstorage

Store random passwords in an encrypted database, to reduce the risk ofcatastrophic disclosure.

Replicatedstorage

Replicate the storage of randomized passwords between at least two servers,installed in at least two physically distinct sites, to reduce the risk of catastrophicdata loss (e.g., due to a disaster at one site).

Controlleddisclosure

Control who (administrators) and what (services and applications) can gainaccess to a given privileged account using static rules and dynamic workflowapproval processes.

Strongauthentication

Support robust authentication of administrators and programs before allowingthem access to privileged accounts. For example, administrators may be requiredto use smart cards or tokens, while programs may use one-time keys, replaced atevery successful login.

Role basedaccess control

Use roles to efficiently manage the rights assigned to people and programs.

Audit logs andreports

Record every attempted and completed access disclosure, to createaccountability regarding the use of privileged accounts.

Auto-discovery

Extract lists of computers from sources such as a directory or an assetmanagement system. Extract lists of privileged accounts by interrogating everycomputer. Automatically classify computers and accounts, so as to automaticallymanage privileged passwords.

Auto-launchedsessions

Rather than displaying passwords to administrators, automatically launchadministrative login sessions (RDP, SSH, SQL Studio, etc.) on their behalf.

Serviceintegration

Notify Windows OS components such as Service Control Manager, Schedulerand IIS of new passwords once they are set, to ensure service continuity afterservice account password changes.

Embeddedpasswordsupport

Enable applications to authenticate themselves and request embeddedpasswords, in order to eliminate passwords stored as plaintext in configurationfiles and program binaries.



10 The Future

Some authentication management processes are relatively new or emerging but, nonetheless, should beconsidered 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 launchsessions - without extra login prompts - into federated systems and applications. For example, a user mightsign into a corporate password management system and follow a link to SalesForce.com or an HR benefitssystem, either of which may reside outside the corporate firewall.

Another example is user-to-user authentication. In some organizations, there are cases where one userneeds to validate the identity of another user prior to providing a business service. For example, a fundstransfer desk in a bank may need to authenticate an investment adviser on the phone before helping himmove money from one account to another. This might be aided by a corporate password managementsystem, where a web UI is exposed that helps users authenticate one another, even if they have never metand don’t know one another.



11 Summary

Password management has grown from simple self-service password reset to a complex, enterprise-scaleplatform 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 technicalinfrastructure:

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 inmore 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 solutioninstead. What other authentication technologies require support automation? What other integrations wouldadd value?

As product capabilities have evolved, what started as simple password reset has grown into enterprise-scaleauthentication management.

Organizations should consider what their authentication management platform should look like in the futureand invest in products today that can meet the full spectrum of current needs and grow to fill future needs.



APPENDICES



A Self-service password reset for locked out users

Users often forget their initial network login password or inadvertently trigger an intruder lockout. Theseusers should be able to get assistance, reset their network or local password, clear intruder lockouts andget back to work.

Since these users have a problem with their workstation login, they cannot access a conventional webbrowser or client/server application with which to resolve their problem. The problem these users face ishow to get to a user interface, so that they can fix their login problem and subsequently access their ownworkstation desktop.

This problem is especially acute for mobile users, who use cached domain passwords to sign into theirworkstation and who may not be attached to the corporate network when they experience a forgottenpassword 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 theirpassword and make it possible to log in.

Hitachi ID Password Manager includes a variety of mechanisms to address the problem of users locked outof their PC login screen. Each of these approaches has its own strengths and weaknesses, as describedbelow:

Option Pros Cons

1 Do nothing: users continue tocall the help desk.

• Inexpensive, nothing todeploy.

• The help desk continues tofield a high password resetcall volume.

• No solution for localpasswords or mobile users.

2 Ask a neighbor: Use someoneelse’s web browser to accessself-service password reset.

• Inexpensive, no clientsoftware to deploy.

• Users may be working aloneor at odd hours.

• No solution for localpasswords or mobile users.

• Wastes time for two users,rather than one.

• May violate a security policyin some organizations.



Option Pros Cons

3 Secure kiosk account (SKA):Sign into any PC with a genericID such as “help” and nopassword. This launches akiosk-mode web browserdirected to the password resetweb page.

• Simple, inexpensivedeployment, with no clientsoftware component.

• Users can reset both localand network passwords.

• Introduces a “generic”account on the network,which may violate policy, nomatter how well it is lockeddown.

• One user can trigger anintruder lockout on the“help” account, denyingservice to other users whorequire a password reset.

• Does not help mobile users.

4 Personalized SKA: Same asthe domain-wide SKA above,but the universal “help” accountis replaced with one personalaccount per user. For example,each user’s “help” accountcould have their employeenumber for a login ID and acombination of their SSN anddate of birth for a password.

• Eliminates the “guest”account on the domain,which does not have apassword.

• Requires creation ofthousands of additionaldomain accounts.

• Requires ongoing creationand deletion of domainaccounts.

• These new accounts arespecial – their passwords donot expire and would likelynot meet strength rules.

5 Local SKA: Same as thedomain-wide SKA above, butthe “help” account is created oneach computer, rather than onthe domain.

• Eliminates the “guest”account on the domain.

• Can be configured to assistmobile users who forgottheir cached domainpassword (by automaticallyestablishing a temporaryVPN connection).

• Requires a small footprinton each computer (the local“help” account.)

6 Telephone password reset:Users call an automatedsystem, identify themselvesusing touch-tone input of anumeric identifier, authenticatewith touch-tone input ofanswers to security questionsor with voice print biometricsand select a new password.

• Simple deployment ofcentralized infrastructure.

• No client software impact.• May leverage an existing

IVR (interactive voiceresponse) system.

• Helpful for remote userswho need assistanceconnecting to the corporateVPN.

• New physical infrastructureis usually required.

• Users generally don’t like to“talk to a machine” soadoption rates are lowerthan with a web portal.

• Does not help mobile userswho forgot their cacheddomain password.

• Does not help unlock PINson smart cards.



Option Pros Cons

8 Physical kiosks: Deployphysical Intranet kiosks at eachoffice location.

• Eliminates generic or guestaccounts.

• May be used by multipleapplications that are suitablefor physically-present butunauthenticated users (e.g.,phone directory lookup,badge management, etc.).

• Costly to deploy – hardwareat many locations.

• Does not help mobile userswho forgot their cacheddomain password.

• Users may prefer to call thehelp desk, rather thanwalking over to a physicalkiosk.

9 GINA DLL: Windows XP:Install a GINA DLL on usercomputers, which adds a “resetmy password” button to thelogin screen.

• User friendly, intuitiveaccess to self-service.


• Works on Windows TerminalServer and CitrixPresentation Manager.

• Requires intrusive softwareto be installed on everycomputer.

• Broken installation orout-of-order un-installationwill render the computerinoperable (i.e., “brick thePC”).

10 GINA Extension Service:Similar to the GINA DLL, butuses a sophisticated serviceinfrastructure to modify the UIof the native GINA, rather thaninstalling a GINA DLL.



• More robust, fault-tolerantinstallation process than theGINA DLL.

• Requires software to beinstalled on every computer.

• Does not work on CitrixPresentation Server orWindows Terminal Server –only works on personalcomputers.

11 Credential Provider: Theequivalent of a GINA DLL, butfor the login infrastructure onWindows Vista/7/8.



• Works on Windows TerminalServer and CitrixPresentation Manager.

• More robust infrastructurethan GINA DLLs onWindows XP.

• Deployment of intrusivesoftware to everyworkstation.



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: [email protected]

File: /pub/wp/documents/from-sspr-to-auth-mgmt/from-sspr-to-authentication-management-1.texDate: 2010-03-25

http://Hitachi-ID.com/

From Password Reset to Authentication Management

Technology

selfservice password

password management

password synchronization

new password

help desk password

password management

authentication management

security challenges