From Password Reset to Authentication Management

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 beneﬁts 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

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.

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.

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 proﬁles
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 ﬁrst appears. To make password synchronization scalable, secure and
reliable, the following challenges must be overcome:

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.

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.

3. Password synchronization is not speciﬁc to a given device or client platform. It works just as well for
users 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 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:

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
ofﬁce 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.

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
certiﬁcate. 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
ofﬂine 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.

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
conﬁdent 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 certiﬁcates.
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.

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

Table 8. Support and Security Challenges in Public Key Infrastructures
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.

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

Table 10. Security and Support Challenges for Full Disk Encryption
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.

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

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 proﬁle 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:

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.

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.

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.

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.

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 beneﬁts
system, either of which may reside outside the corporate ﬁrewall.
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.

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.

APPENDICES

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.

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 conﬁgured 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 identiﬁer, 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.

Option Pros Cons
8 Physical kiosks: Deploy
physical Intranet kiosks at each
ofﬁce 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.
their cached domain
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.
their cached domain
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.
their cached domain
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.

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

From Password Reset to Authentication Management

More Related Content

What's hot (20)

Similar to From Password Reset to Authentication Management (20)

More from Hitachi ID Systems, Inc. (19)

Recently uploaded (20)

From Password Reset to Authentication Management