Large Scale Password Management with Hitachi ID Password Manager

Large Scale

Password Management With Hitachi ID Password Manager

1 Introduction 1

2 Why do we still use passwords? 3

3 How to compose and manage passwords securely? 4 3.1 Secret passwords ...... 4 3.2 Pass phrases ...... 5 3.3 Memorable passwords ...... 5

4 Password management guidelines for application developers 6

5 Multi-factor authentication 7

6 Usability, IT support cost and security 8

7 Basic password management 9 7.1 Password synchronization ...... 9 7.2 Password policy enforcement ...... 9 7.3 Self-service password reset ...... 10

8 Technical challenges 11 8.1 Users locked out of their PC (Windows login password) ...... 11 8.2 Filesystem encryption and pre-boot passwords ...... 13 8.3 Off-site users – expired and forgotten passwords ...... 14 8.4 Locally cached passwords ...... 15 8.5 Replication delays between Active Directory domain controllers ...... 16

9 Network architecture 17

10 Maximizing user adoption 20

11 Access to Hitachi ID Password Manager from smart phones 22

12 Telephony integration (IVR) 24

13 Return on investment 26

i Large Scale Password Management With Password Manager

14 Platform support 28

1 Introduction

This document describes self-service credential management using Hitachi ID Password Manager. It links business problems to technology and describes the beneﬁts of automation and self-service.

The remainder of this document covers:

• Why do we still use passwords? Many people wonder why password management is still needed? Aren’t passwords going away soon? This is an overview of why passwords will likely be with us for years to come.

• How to compose and manage passwords securely? Given that users will have passwords for years, some advice on how to choose secure, memorable passwords is offered.

• Password management guidelines for application developers It’s not only users who deal with passwords. Application developers must write password handling logic and user interfaces. Here is guidance for them.

• Multi-factor authentication Passwords can be compromised, so multi-factor authentication is often recommended. Why this is so and what to do is summarized here.

• Usability, IT support cost and security The impact of poor password management on organizations is high cost and weak security, as described here.

• Basic password management Hitachi ID Password Manager automates basic password management processes, as described here.

• Technical challenges Basic password management is great – but there are many scenarios where user location, use of encryption and cached passwords interfere. These scenarios, and how Password Manager addresses each one, are described.

• Network architecture Password Manager is deployed to corporate networks, as described here.

• Maximizing user adoption The value of password management hinges on user adoption. How to increase adoption rates and consequently maximize RIO is described here.

• Access to Password Manager from smart phones Users increasingly prefer to interact with corporate services from their smart phones. This is supported by Password Manager as described here.

• Telephony integration (IVR)

Some organizations expose self-service management of passwords and PINs to a users via phone calls, and this is supported by Password Manager.

• Return on investment Password Manager can generate real, measurable cost savings for organizations. This section shows how to estimate these savings.

• Platform support Password Manager can manage passwords and other credentials across a wide range of systems and applications.

2 Why do we still use passwords?

The end of passwords has been predicted for decades. Biometrics, smart cards, one time password tokens and more have been offered up as alternatives and many of these are gaining market share.

In reality, passwords are likely to remain popular for a long time:

1. Passwords are cheaper to deploy than any alternative, though supporting passwords (forgotten, locked out) can be costly.

2. Some types of credentials can only be used on compatible devices and in certain circumstances:

(a) Smart cards plug into card readers, which are mainly made for PCs (desktops and laptops) – rarely for tablets or smart phones. (b) One time password tokens only work where there is a network connection – this makes them unsuitable for signing into devices which are sometimes off-line. (c) Every kind of biometric requires a sensor – ﬁnger print reader, retina scanner, camera, micro- phone, etc. Not every device a user might want to sign into has the requisite sensors. (d) For every biometric, there are some users who physically cannot enroll – amputees, people whose ﬁngers are too small, people with retinal or iris damage, etc.

3. In many cases, credentials other than passwords are combined with passwords to create stronger authentication. For example, tokens and smart cards are commonly combined with PINs (just numeric passwords).

4. Many solutions marketed as replacements for passwords really just externalize the login process out of an application, to a shared infrastructure, which in all likelihood does use a password. This is true of Kerberos, LDAP authentication, federation with OAuth and SAML, etc.

5. Many legacy applications are simply incompatible with any other credentials – user logins are with an ID and password and nothing else.

Only when most applications can externalize their login process will organizations be able to seriously contemplate the end of passwords.

3 How to compose and manage passwords securely?

A user choosing a new password should attempt to meet two somewhat contradictory objectives:

1. The password should be a secret – harder for others to guess.

2. The password should be easy to remember and reasonably convenient to type.

3.1 Secret passwords

Truly secret passwords cannot be based on trivial choices: the user’s name, login ID, e-mail address, phone number or a dictionary word. The password should include enough characters, drawn from a large enough set of possible characters, that brute force password guessing will be infeasible.

Given a set of characters S and a password length L, the number of possible passwords is SL. Here are some examples:

Character set Size of set Password length Number of possibilities 4-digit PIN 0-9 10 4 10,000 Short, lowercase a-z 26 6 308,915,776 Longer, mixed-case a-z, A-Z 52 8 53,459,728,531,456 Longer, digits, a-z, A-Z, 0-9, 95 8 6,634,204,312,890,625 punctuation, symbols mixed-case, space

These numbers sound large, and if an attacker must try out guessed passwords over a network, even a short lowercase password would be reasonably secure. The problem is that sometimes attackers can acquire copies of hashed (one way encryption) passwords and when this happens, they can test guesses against actual password hashes much more quickly – as much as 350 billion guesses per second with specialized hardware (multiple GPUs).1

How complex a password to choose depends on how much the user trusts the system they sign into to not be compromised, in the sense of encrypted passwords being extracted, and what the adverse outcome would be in the event of such an attack, undisclosed, followed by unauthorized access to the user’s account.

Note that if a system is successfully compromised, but the attack is disclosed promptly, there isn’t much of a problem – just change the password before the account is compromised, which in all likelihood (assuming a reasonably complex password and assuming that attackers cannot afford specialized password guessing hardware) would take days or weeks.

All that being said, it’s reasonably easy for users to choose passwords that are at least 8 characters long and include lowercase, uppercase, digits and punctuation marks. Changing these passwords periodically limits the amount of time that an attacker has to compromise the account, even in the event of an undisclosed compromise of the database of password hashes.

1https://arstechnica.com/information-technology/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/

3.2 Pass phrases

Some people argue that pass-phrases - basically sentences comprising a few words - are a better approach. If users choose real sentences and type them in all lowercase letters, this is actually not true. There are about 60,000 words in the English language (in a relatively large dictionary). There are in principle 600005 possible 5-word sentences, but word frequency is very uneven and grammar further restricts legal sequences. In practice, each word represents about 10 bits of entropy2, so 5 words have 50 bits of entropy – 250 realistic combinations, or 1,125,899,906,842,624 combinations – less secure than the aforementioned 8 character password.

3.3 Memorable passwords

The other constraint on passwords is that they be memorable. There are lots of strategies for this – trans- posing certain letters to digits, selecting the ﬁrst or second letter from each word in a memorable sentence, inserting punctuation marks, etc. There are good guidelines on the web:

• https://www.bu.edu/tech/support/information-security/security-for-everyone/how-to-choose-a-strong-password/

• https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html

• https://www.wikihow.tech/Create-a-Secure-Password

2http://www.sciencedirect.com/science/article/pii/S0019995864903262

4 Password management guidelines for application developers

Application developers should follow some best practices, both to encourage secure user behaviour and to minimize user frustration:

1. Support external identification and authentication with as much flexibility as possible, so that users don’t need application-specific credentials at all:

(a) On-premises applications: externalize identification and authentication to Active Directory, by prompting users to enter their AD passwords and/or using integrated Windows authentication (Kerberos). (b) Corporate SaaS applications: support both local credentials and external logins via SAML, where the consuming organization has a federated identity provider (IdP). (c) Internet-facing applications: Use fully qualified e-mail addresses for user IDs, so users need not remember any new identifiers. (d) Consumer-facing applications: Externalize authentication using OAuth, so users can sign in with their social network credentials (Google, Live.com, Facebook, etc.).

2. Support strong passwords, warn about weak passwords but give users maximum ﬂexibility vis-a-vis passwords they choose.

(a) Users may wish to incorporate mixed case, spaces, digits or punctuation marks in their passwords – let them! (b) Users may select long passwords – allow them to! (c) Warn users that choose a password whose complexity does not meet a policy threshold, but don’t necessarily force them to select a stronger password. Strong passwords should only be forced on insiders, who are typically subject to corporate password policy rules.

3. Encourage users to change passwords regularly, via prompts at the login prompt and e-mailed to users. Force regular password changes if corporate policy mandates this.

In general, Internet-facing applications should be more permissive while Intranet-facing should be more restrictive.

Using a password management system, such as Hitachi ID Password Manager, organizations can apply strong controls over all passwords, rather than trying to implement policies inside applications, one at a time.

5 Multi-factor authentication

Despite best efforts, password security can sometimes be compromised. There are three main ways in which passwords are exposed:

1. Poor password management practices – users choose easily guessed passwords, never change their passwords, write them down or share them. Effective policy and automation can help mitigate these problems, as described in this document.

2. The user’s endpoint device is compromised with key-logging malware. An attacker can then see what a user types, so it makes no difference how good the user’s password is – when the password is plainly visible.

3. A system or application that users sign into is compromised, which may lead to three types of data leak:

(a) User passwords are exposed in plain-text, at login time, as users sign in. In this case, the attacker gains access to some passwords, as they are used. (b) User passwords are in bulk, in plain-text (badly written application). In this case, the attacker gains access to all of the passwords on the system at once. (c) User passwords are in bulk, in a strongly hashed format. In this case, the attacker can carry out high-speed attacks against password hashes, guessing some but not others.

Since it is impossible to guarantee that none of these attacks will happen, organizations increasingly turn to multi-factor authentication (MFA). With MFA, users sign in with two or more credentials. For example, a user might enter a password or PIN, combined with a pseudo-random number displayed on a hardware token or app. A user might type a PIN sent to their personal e-mail address or mobile phone number. Users might insert a smart card into a reader, or provide a biometric sample, such as a ﬁnger print scan.

With most of these schemes, one of the credentials is a password or PIN (which, in turn, is just a short and numeric password). The other credential varies, but mainly is intended to be secure against key-loggers and against disclosure of the password database.

6 Usability, IT support cost and security

Passwords present a number of problems for organizations:

1. Users have too many passwords and have a hard time remembering them all.

2. Password management is exacerbated when different passwords expire on different schedules, are changed via different user interfaces and are subject to different policies.

Users respond to these problems by

1. Choosing trivial (and insecure) passwords.

2. Avoiding password changes.

3. Writing down their passwords, effectively reducing logical security to be equal to physical security.

Users often forget their passwords or mistype them, creating high IT support call volumes at the help desk – this is both inconvenient for users and costly for the organization.

The impacts of poor password management are:

1. User frustration.

2. High IT support cost.

3. Weak authentication.

7 Basic password management

Password management systems address the problems described above by reducing the number of passwords users must manage (synchronization), enforcing a uniform password policy and allowing users to resolve their own login problems (self-service password reset):

7.1 Password synchronization

Password synchronization is any process or technology that helps users to maintain a single password, subject to a single security policy, across multiple systems.

Password synchronization is an effective mechanism for addressing password management problems in medium to large organizations:

• Users with fewer passwords tend to remember them.

• Simpler password management means fewer problems and fewer help desk calls.

• Users with fewer passwords are less likely to write them down.

There are two ways to implement password synchronization:

• Transparent password synchronization, where native password changes, that already take place on a common system (example: Active Directory) are automatically propagated through the password management system to other systems and applications.

• Web-based password synchronization, where users change all of their passwords at once, using a web application.

One of the core features of Hitachi ID Password Manager is password synchronization.

Password Manager implements both transparent and web based password synchronization.

7.2 Password policy enforcement

Hitachi ID Password Manager is normally conﬁgured to enforce a uniform password policy across all systems, to ensure that any new password will be acceptable to every integrated system. This provides the most clear and understandable experience to users. Password Manager is conﬁgured such that it will never accept or propagate a password that will not meet this global password policy.

For instance, in the case of an organization that has both Windows Active Directory (AD) and z/OS passwords, where users may enter very long passwords on AD but only 8 characters on the mainframe, Password Manager can require that passwords be exactly 8 characters long. Alternately, Password Manager can support longer passwords, but truncate them when it updates the mainframe (users generally prefer a ﬁxed length, as it is easier to understand).

All systems enforce two types of password rules:

• Complexity requirements ensure that users do not select easily-guessed passwords. Example rules are: disallowing any permutation of the user’s login ID, password history, requiring mixed letters and digits, forbidding dictionary words, etc.

• Character set and length limits on what can be physically stored in the password ﬁeld on a given system.

A global password policy is normally created by combining and strengthening the best-of-breed complexity requirements from each system affected by the policy. Password Manager then combines these with the most restrictive storage constraints. This forces users to select strong, secure passwords on every system.

The alternative, of deﬁning different password policies for every target system or for groups of target systems, is less user friendly. To update their passwords, users must select a system, choose a password, wait for the password update to complete, choose another system, select and input a different password, etc. Users must then remember multiple passwords and will continue to experience many password problems. It has been shown that users with many passwords have a strong tendency to write down their passwords.

7.3 Self-service password reset

Self-service password reset is deﬁned as any process or technology that allows users who have either forgotten their password or triggered an intruder lockout to authenticate with an alternate method and repair their own problem, without calling the help desk.

Users who have forgotten their password or triggered an intruder lockout may launch a self-service application using an extension to their PC login prompt, using their own or another user’s web browser, using an app on their smart phone or through a telephone call. Users establish their identity, without using their forgotten or disabled password, by entering a PIN sent to their phone, by answering a series of personal questions, using a hardware authentication token or by providing a biometric sample. Users then either select a new password or just clear a lockout on their account.

Self-service password reset expedites problem resolution for users and reduces help desk call volume. It can also be used to ensure that password problems are only resolved after strong user authentication, eliminating an important weakness of many help desks: social engineering attacks.

One of the core features of Hitachi ID Password Manager from Hitachi ID Systems is self-service password reset.

8 Technical challenges

In practice, synchronizing passwords and offering self-service password reset can be more difﬁcult to realize than might ﬁrst appear. Users work off-site, without connectivity. Their PCs may be protected with full disk encryption, and users may forget their pre-boot password. Passwords are cached locally on user devices, and users want access to the credential management system from their phones, not just from a corporate PC.

Hitachi ID Password Manager addresses each of these challenges:

8.1 Users locked out of their PC (Windows login password)

Problem:

Users sometimes forget their primary PC login password or trigger an intruder lockout. It is desirable to enable these users to access self-service to resolve their problem, but there is a catch: they cannot sign into their PC so cannot access a conventional web browser or other PC application. How then can they access self-service?

The technical challenge is how to connect users to a self-service mechanism from a pre-login context. The mechanism offered must be evident (or users won’t ﬁnd it), easy to use and secure.

There are three contexts that complicate this problem:

1. When a user is locked out of the OS login screen; and

2. When a user is physically off-site; or

3. When a user is unable to unlock the encrypted drive of his PC, at a pre-boot password prompt.

Solution:

Hitachi ID Password Manager includes a variety of capabilities to address this problem:

Option Hitachi ID Systems Software Offering Notes and Recommendations 1 Hitachi ID Reset the password using an app on the A proxy server, hosted in the Mobile user’s phone. cloud, must broker Access communication between the user’s phone, which is connected to the public Internet and typically has no VPN connection and the on-premises Password Manager server.

Option Hitachi ID Systems Software Offering Notes and Recommendations 2 interactive Either extend the call ﬂow in an existing This mechanism is especially voice IVR system or deploy Hitachi ID helpful to reset forgotten PINs response Telephone Password Manager, included to OTP tokens, which are often (IVR) with Password Manager, to allow users to used to sign into the VPN. password reset forgotten passwords via phone call. reset Authentication may be via touch-tone input, speech to text or biometric voiceprint matching. 3 Domain Allow users to sign into their Two drawbacks: the user must secure network-attached PC with a generic be on-premises and a generic kiosk domain account, such as "help" (typically account is created on the account with no password). Launch a kiosk-mode network. One advantage: easy (SKA) web browser instead of the Windows to deploy. desktop, to connect users to the password-reset system. 4 Credential Adds a new tile to the Windows login Very popular, especially with Provider screen, used to launch the Hitachi ID VPN integration to support (CP) Login Assistant, which enables access to off-site users. self-service for locked out users.

8.2 Filesystem encryption and pre-boot passwords

Problem:

Many organizations deploy drive encryption software to user PCs. This helps prevent data compromise in the event that a laptop is lost or stolen.

Drive encryption software is often conﬁgured to prompt the user to type a password before the OS boots up – a very secure conﬁguration. This password is often synchronized with the user’s AD password.

Unfortunately, when users forget their pre-boot password, the unlock process can be quite tedious, as it requires that the user calls the help desk, authenticate themselves and then exchange cryptographic challenge and response codes with the technician on the phone. These can be frustrating and costly IT support calls.

Solution:

Hitachi ID Password Manager enables users whose PC is protected with a drive encryption software who have forgotten their pre-boot password to unlock their PC.

The process for encrypted drive unlock is as follows:

1. The user selects the “unlock” user interface at the boot prompt of the drive encryption software. Note that this is available before the operating system boots.

2. The user calls the help desk phone number and selects the “PC boot problem” menu option. This is conﬁgured on the existing help desk telephone system.

3. The user’s phone call is connected to Hitachi ID Telephone Password Manager - the self-service telephone user interface component of Password Manager.

4. The user identifies himself. There are several identification options, including touch-tone input of a numeric identifier such as the user’s employee number or speech-to-text entry of the user’s network login ID.

5. The user authenticates himself. There are several authentication options, including touch-tone input of answers to security questions (e.g., driver’s license number, date of birth, social security number, etc.) or biometric voice print veriﬁcation.

6. The user then acts as a relay between the challenge strings displayed by his encryption software and the response strings which Telephone Password Manager reads back to the user. The user keys strings he sees on the screen into the phone and keys strings he hears on the phone into his PC.

Note that drive unlock is also possible using an Android or iOS smart phone app, instead of a phone call.

8.3 Off-site users – expired and forgotten passwords

Problem:

Users who work off-site, away from the corporate network experience password management problems that on-site users do not:

• Remote users with passwords cached on their PC are not able to change their passwords while off- line (this is a native and reasonable limitation imposed by Windows - and applies with and without Hitachi ID Password Manager).

• Users who are remote for extended periods of time are not reminded by the OS to change their password and consequently their network password silently expired. This impairs their ability to access e-mail via a web UI (e.g., Outlook Web Access or similar), launch VPN connections and more.

• When an off-site user forgets their domain password, which is locally cached, they cannot resolve the problem until they return to the ofﬁce. While these users can call the help desk and get their domain password reset, the locally cached password is unaffected and so the user’s PC remains unusable. While this type of support incident is infrequent, the impact on business users can be huge.

Solution:

Password Manager is uniquely able to support off-site users, even when their PC is initially not attached to any network.

Password Manager includes a solution for such remote, off-line users who rely on locally cached passwords to sign into their PC. This solution does require a client software on user PCs. The user selects a ’Forgot my password’ tile at the login prompt, which launches the Password Manager Login Assistant. This CP establishes a temporary connection to a specially-provided, time-limited, IP-ﬁltered VPN account. The credentials for this connection are encrypted in the registry, are static and are not known to the user.

Once a network connection is established, Login Assistant launches a locked down, kiosk-mode web browser using which the user signs into Password Manager – for example, by entering a PIN sent to their mobile phone and then answering security questions. The user resets their forgotten password and an Ac- tiveX component re-authenticates the user’s PC to the domain, over the VPN, thereby updating the user’s locally cached domain password.

When the user closes the browser, the VPN connection is terminated and the user is returned to the PC login prompt, from which they can sign into the PC using the new password.

8.4 Locally cached passwords

Problem:

Windows PCs cache user passwords – typically the primary password a user types at the login screen, which was authenticated against Active Directory. This is done for two reasons:

1. To enable users to log into their PC while detached from the network (example: traveling laptop).

2. To automatically sign the user into resources, such as shared ﬁle and print services, without having to prompt the user to retype his password.

When a user changes his password using the network client software on the PC (e.g,. ctrl-alt-del method), the network client automatically updates its cached password.

On the other hand, if a user is logged into his PC and simultaneously his password is reset elsewhere on the network – for example by the help desk or by the user himself on a second concurrently logged in PC, then the cached password on the PC will not change – it will simply be wrong.

Similarly, if the user forgets his password and it is reset on the network while his PC is disconnected (e.g., remote), the new password will not be copied to the PC until it is re-attached to the network.

An invalid, cached password causes several problems:

1. If the user’s PC is not attached to the network when his password changes, the user will be unable to use the new password on his PC until he re-attaches to the network.

2. If the user’s PC is attached to the network and the user attempts to access a network resource (ﬁle server, print queue, etc.), the PC may send an incorrect, cached password to the network resource, which will increment the user’s “number of invalid login attempts” counter. Repeated connection attempts will trigger an intruder lockout.

Solution:

An ActiveX component included with Hitachi ID Password Manager can be used to:

• Update cached network credentials on a PC after a successful web-based password change:

– This addresses the issue of intruder lockouts caused by PCs continuing to attempt to sign into network resource using cached, no-longer-valid passwords. – This also enables password reset services for off-site users who only authenticate to their PC using cached credentials, rather than validating those credentials against a domain controller.

• Notify other login-related components, such as drive encryption products, that they should adopt the user’s new AD password.

8.5 Replication delays between Active Directory domain controllers

Problem:

Active Directory does not propagate cleared intruder lockout ﬂags on an expedited schedule. This can create problems for remote users who inadvertently trigger a lockout and subsequently call a central help desk for assistance. The help desk will typically clear the user’s lockout on a domain controller near the help desk. This lockout may take hours to reach the domain controllers against which the user wishes to authenticate or which support network services that the user wishes to access.

This problem is especially acute in global organizations, with hundreds of domain controllers that employ a global IT support function.

Note that AD password change replication is described here:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772726(v=ws.10)

Solution:

Please refer to Subsection 8.5 on Page 16 for an overview of the intruder lockout replication problem in Active Directory.

Hitachi ID Password Manager uniquely circumvents the problem of slow replication of cleared intruder lockouts between Active Directory domain controllers by automatically directing password resets and cleared intruder lockouts to a select set of domain controllers, which the user is most likely to access:

• DCs on the user’s home site, based on the user’s home directory UNC and the IP address of the server that hosts this UNC.

• DCs on the user’s current site, based on the user’s web browser IP address (this only applies to self-service password reset).

• DCs mapped to either of these sites by an administrator-conﬁgured rule set. For example, at global or regional data centers.

9 Network architecture

Hitachi ID Password Manager is designed for:

• Security: Password Manager is installed on hardened servers. All sensitive data is encrypted in storage and transit. Strong authentication and access controls protect business processes.

• Scalability: Multiple Password Manager servers can be installed, using a built-in data replication facility. Workload can be distributed using any load-balancing technology (IP, DNS, etc.). The end result is a multi- master, active-active, geographically distributed architecture that is very easy to setup, as replication is handled at the application layer.

• Performance: Password Manager uses a normalized, relational and indexed database back end. All access to the database is via stored procedures, which help to minimize communication overhead between the application and database. All Password Manager code is native code, which provides a 2x to 10x performance advantage as compared to Java or .NET

• Openness: Open standards are used for inbound integration (SOAP) and outbound communications (SOAP, SMTP, HTTP, etc.).

• Flexibility: Both the Password Manager user interface and all functionality can be customized to meet enterprise requirements.

• Low TCO: Password Manager is easy to set up and requires minimal ongoing administration.

Figure 1 on Page 18 illustrates the Password Manager network architecture when deployed on-premises:

• Users normally access Password Manager using HTTPS from a web browser.

• Multiple Password Manager servers may be load balanced using either an IP-level device (e.g., Cisco Local Director, F5 Big/IP) or simply using DNS round-robin distribution.

• Users may interact with Password Manager via an app on their phone. Where this is allowed by an organization, the app on the phone connects via HTTPS to a Linux/Tomcat proxy server in the cloud or on the an organization DMZ. Simultaneously, each Password Manager server keeps open a pool of HTTPS connections to the same proxy system(s). The proxies broker communication from user phones to the on-premises Password Manager server(s) after authenticating both connections. The app is authenticated by offering up a key, which was deployed earlier at phone activation time and which may be revoked at any time.

• Users may make a voice phone call to an IVR system and be authenticated either using touch-tone input of personal information or using a voice print. Authenticated users may initiate a password reset.

Figure 1: Password Manager network architecture

Native password change Password synch trigger systems SaaS apps

AD, Unix, z/OS, Mobile LDAP, iSeries proxy

z/OS - local agent Mobile UI Manage “Cloud” Validate pw

Hitachi ID servers Load balancers Reverse web proxy VPN server Managed endpoints with remote agent: Replication AD, SQL, SAP, Notes, etc IVR server MS SQL databases

Hitachi ID Notifications servers and invitations Data center B Tickets E-mail Firewalls system System of Remote data center Ticketing record TCP/IP + AES system

HR Managed Various protocols endpoints Data center A Secure native protocol Proxy server HTTPS (if needed)

• Password Manager connects to most target systems using their native APIs (application programming interfaces) and protocols and thus requires no software to be installed locally on those systems.

• Local agents are provided for Unix/Linux servers and z/OS mainframes. A local agent is recommended for z/OS – on Unix/Linux it’s only included in case there is no SSHD. Use of these agents improves transaction security, speed and concurrency.

• Where target systems are remote and communication with them is slow, insecure or blocked by a ﬁrewall or NAT, a Password Manager proxy server may be co-located with the target system in the remote location. In this case, servers in the main Password Manager server cluster initiate fast, secure connections to the remote proxies, which decode these transactions and forward them to target systems locally, using native, slow and/or insecure protocols.

• Password Manager can look up and update user proﬁle data in an existing system, including HR databases (ODBC), directories (LDAP) and meta-directories (e.g., WMI to Microsoft ILM).

• Password Manager can send e-mails to users asking them to complete enrollment, participate in workflow processes or to notify them of events impacting their profiles. Over 300 events can trigger e-mail notification.

• Password Manager can create tickets on many types of incident management systems, either record- ing completed activity or requesting assistance (security events, user service follow-up, etc.). Over 300 events can trigger ticket generation. Binary integrations are available for 20 help desk applications and open integration is possible using mail, ODBC, SQL and web services.

10 Maximizing user adoption

In many organizations, deployment of a credential management system requires a user enrollment process. Enrollment may be to get users to:

1. Answer security questions; 2. Install and activate an app on their smart phone; 3. Provide their mobile phone number or personal e-mail address; 4. Attach accounts with non-standard IDs to their proﬁle; 5. Provide biometric samples, such as a voiceprint; 6. Review and accept corporate policy documents.

Where enrollment is required, it is helpful for the credential management system to automate the process by identifying users who must be enrolled, inviting and reminding them to enroll and provide a strongly authenticated enrollment user interface.

Hitachi ID Password Manager includes built-in infrastructure to securely and automatically manage the user enrollment process:

• By monitoring one or more systems of record, Password Manager automatically creates new and removes old proﬁle IDs.

• New users and existing users with incomplete proﬁles are automatically invited to complete their proﬁles:

1. Answer security questions. 2. Install and activate Mobile Access on their smart phones. 3. Provide contact information, such as mobile phone number or personal e-mail address, to which a PIN can be sent.

• Invitations to enroll may be e-mailed to users.

• Users may be more forcefully reminded to enroll by having a web browser automatically open to the enrollment page when they log into the network.

• Users may be forced to enroll, by opening a kiosk-mode web browser to the enrollment page when they sign into the network, and blocking access to the Windows desktop until users complete their proﬁle. This process is typically controlled by placing users into a “mandatory enrollment” AD group and attaching a suitable GPO to that group.

• To enroll, users must ﬁrst authenticate. This is normally done by leveraging an existing strong authen- ticator – such as a network password or a token.

• A single, integrated enrollment system supports collecting answers to security questions, mapping different login IDs, on different systems back to their owners, activating a smart-phone app, collecting mobile phone numbers or personal e-mail addresses and collecting biometric voice print samples.

The enrollment system in Password Manager includes schedule controls. For example, the maximum number of invitations to send daily can be limited, as can the frequency of invitations per user. Days-of- week during which to send invitations are identiﬁed as are holidays during which no invitations should be sent.

Figure 2 shows a dashboard that tracks enrollment progress.

Figure 2: Screen shot: Enrollment Statistics

11 Access to Password Manager from smart phones

Since Hitachi ID Password Manager is a sensitive security application, with privileged access to other systems in an organization and/or and with access to sensitive personal data, most organizations are unwilling to expose Password Manager directly to the public Internet (regardless of where it is hosted). This creates a problem for mobile device access to self-service, as illustrated in Figure 3.

Figure 3: Outbound connections are routine, inbound connections are risky and rarely permitted Risky, controversial, likely not allowed

Simple, uncontroversial firewall configuration

IAM server Personal Firewall Firewall device

Internet DMZ Private corporate network

Hitachi ID Systems has developed a solution to this problem, by installing and activating an app natively on iOS and Android devices and hosting a proxy server in the cloud. This arrangement is shown in Figure 4.

Using this architecture:

1. An app is installed on user devices.

2. Users sign into Password Manager with their PC and ask to activate their device.

3. The PC-based web UI displays an activation QR ode.

4. The user runs the app on their device, which scans this QR code.

5. The QR code includes encryption key material and a URL for a proxy service, in the cloud (i.e., on the public Internet).

6. Users use the app to (indirectly) access the on-premises Password Manager web portal.

7. The app connects to the cloud proxy, requesting content from the on-premises portal.

8. The proxy checks key material provided by the app and may discard connection attempts. In this way, connections from regular browsers or devices which have not been correctly activated for a particular Password Manager instance are easily discarded.

9. Simultaneously, a service on the Password Manager server connects to the proxy server, asking for page requests to fulﬁll.

10. The proxy passes requests from mobile devices to connections from the Password Manager server.

11. All connections that cross the corporate perimeter ﬁrewall in this architecture are outbound – from the Password Manager server to the cloud proxy.

12. All connections are encrypted.

Figure 4: Cloud proxy architecture

Internet

Personal Firewall Firewall IAM server device (2) HTTPS request: DMZ Private corporate “Includes userID, network Outbound connections only (1) deviceID” Worker thread: “Give me an HTTP request”

Cloud (3) proxy Message passing system

12 Telephony integration (IVR)

Some organizations expose self-service credential management on their automated phone system. This is a popular way to support users who have VPN login problems, for example.

Overview:

Hitachi ID Telephone Password Manager is a turn-key telephone user interface bundled with the Hitachi ID Password Manager credential management solution. It enables organizations to quickly and inexpensively offer self-service password reset, PIN reset and encrypted drive unlock to users via a telephone call, without having to conﬁgure a complex IVR system.

Features:

Telephone Password Manager supports self-service management of login credentials and unlock of encrypted drives through:

• Caller identification: Users who call Telephone Password Manager typically identify themselves by typing a personal identifier on a touch-tone telephone keypad. The identifier may be a pre-existing numeric ID, such as an employee number or a letters-to-digits mapping of an alpha-numeric ID, such as the user’s network login ID.

• Authentication: Once they have entered a claimed identity, users must prove that it’s really them on the call. Telephone Password Manager supports authentication with a hardware token (e.g., RSA SecurID), by prompting the user to key in answers to numeric security questions on a touch-tone telephone keypad (e.g., driver’s license number, SSN, date of birth, etc.), by sending a PIN to the user’s mobile phone, which the user must key in, or by using an optional biometric voice veriﬁcation module.

• Password reset: Authenticated callers can initiate a password reset. This may be applied to one or all of their accounts and the new password may either be randomly generated and read out to the user or user-selected. New passwords may be set to expire after ﬁrst use.

• PIN reset: Authenticated callers can also use Telephone Password Manager to reset the PINs on their RSA SecurID tokens. A randomly-generated or a user-speciﬁed PIN may be used.

• Encrypted drive unlock: Users with a drive encryption program protecting their computer can use Telephone Password Manager to automate the unlock process in the event that they forgot the password that they normally type pre- boot.

• Text to speech:

Telephone Password Manager is normally conﬁgured to play .WAV audio ﬁles as prompts for user input. It also includes a text to speech mechanism that makes it easier to develop new navigation menus and defer having to record new voice prompts.

• Speech to text: While text input into Telephone Password Manager is usually made with a touch-tone keypad, Telephone Password Manager can be conﬁgured to recognize small dictionaries of spoken words, so that users can make alphanumeric input by speaking the names of letters and digits.

• VoIP integration: Telephone Password Manager can be connected to a voice-over-IP network and conﬁgured to accept VoIP calls.

Beneﬁts:

Telephone Password Manager lowers IT support costs and improves user service by enabling remote or locked out users to resolve login problems related to their password, hardware token or encrypted drive without calling the help desk.

Telephone Password Manager can improve the security of IT support processes by authenticating users with biometric voice-print veriﬁcation prior to offering credential support services.

13 Return on investment

Deploying Hitachi ID Password Manager saves money for three groups of people in an organization:

• Users: Password synchronization reduces the incidence of password problems. In most organizations, over 80% of problems are eliminated. Accordingly, users waste less time making unsuccessful attempts to log into systems.

• Support staff: Both password synchronization and self-service password resets eliminate calls to the help desk. Together, they normally reduce password-related call volume by over 90%. Once calls reach the help desk, they are resolved much more quickly, using a single tool that integrates caller authentication, multiple password resets and creation of problem tickets. Using a web browser, support staff can resolve password calls in 1-2 minutes.

• System administrators: Without Password Manager, most support organizations escalate some password calls to system administrators. This is done when the support organization does not have training or security clearance to reset passwords on the systems in question. Password Manager eliminates password problem escalation.

Example savings calculation

The following example illustrates how Password Manager reduces the cost of password management:

• 10000 users experience 3000 password problems per month. Users spend 10 minutes with a password problem before calling for help.

• The help desk takes 10 minutes to resolve password problems.

• 1/6 of calls are escalated from the help desk to system administrators.

• Password Manager eliminates 80% of password problems, and reduces problem resolution time 2 minutes.

Monthly cost Initial Password Manager Savings Users 3000 calls × 20 minutes × $40/hr 600 calls × 12 minutes × $40/hr = $40,000 = $4,800 $35,200 Help desk 3000 calls × 10 minutes × $40/h 600 calls × 2 minutes × $40/hr = $20,000 = $800 $19,200 Administrators 500 calls × 5 minutes × $40/hr = $1,670 0 $1,670 Monthly Total $61,670 $5,600 $56,070

To estimate the cost savings in your organization, try our on-line calculator at: https://Hitachi-ID.com/calculator/

14 Platform support

Hitachi ID Password Manager comes with connectors for many popular systems and applications. All connectors are included in the base price and almost all of them can both read (discover accounts, entitlements, attributes) and write (passwords, attributes, accounts, groups, etc.).

Out-of-the-box connectors

Directories: Databases: Server OS – X86/IA64: Active Directory and Azure AD; any Oracle; SAP ASE and HANA; SQL Windows: NT thru 2016; Linux and LDAP; NIS/NIS+ and eDirectory. Server; DB2/UDB; Hyperion; Caché *BSD. MySQL; OLAP and ODBC. Server OS – Unix: Server OS – Mainframe: Server OS – Midrange: Solaris, AIX and HP-UX. RAC/F, ACF/2 and TopSecret. iSeries (OS400); OpenVMS and HPE/Tandem NonStop. ERP, CRM and other apps: Messaging & collaboration: Smart cards and MFA: Oracle EBS; SAP ECC and R/3; JD Microsoft Exchange, Lync and Any RADIUS service or SAML IdP; Edwards; PeopleSoft; Office 365; Lotus Notes/Domino; Duo Security; RSA SecurID; Salesforce.com; Concur; Business Google Apps; Cisco WebEx, Call SafeWord; Vasco; ActivIdentity and Objects and Epic. Manager and Unity. Schlumberger. Access managers / SSO: Help desk / ITSM: Drive encryption: CA SiteMinder; IBM Security ServiceNow; BMC Remedy, Microsoft BitLocker; McAfee; Access Manager; Oracle AM; RSA RemedyForce and Footprints; JIRA; Symantec Endpoint Encryption and Access Manager and Imprivata HPE Service Manager; CA Service PGP; CheckPoint and Sophos OneSign. Desk; Axios Assyst; Ivanti HEAT; SafeGuard. Symantec Altiris; Track-It!; MS SCS Manager and Cherwell. Server health monitoring: HR / HCM: Extensible / scriptable: HP iLO, Dell DRAC and IBM RSA. WorkDay; PeopleSoft HR; Ultipro; CSV files; SCIM; SSH; SAP HCM and SuccessFactors. Telnet/TN3270/TN5250; HTTP(S); SQL; LDAP; PowerShell and Python. Hypervisors and IaaS: Mobile management: Network devices: AWS; vSphere and ESXi. BlackBerry Enterprise Server and Brocade Fabric OS; CheckPoint MobileIron. SecurePlatform; Cisco ACS, ASA, IOS, Nexus and PIX; Dell DRAC; F5 BigIP; HP iLO; HP Procurve; IBM RSA; Juniper JunOS and ScreenOS; PaloAlto firewalls and Riverbed SteelHead. Filesystems and content: SIEM: Management & inventory: Windows/CIFS/DFS; SharePoint; Splunk; ArcSight; RSA Envision and Qualys; McAfee ePO and MVM; Samba; Hitachi Content Platform QRadar. Any SIEM supporting Cisco ACS; ServiceNow ITAM; HP and HCP/Anywhere; Box.com and SYSLOG or Windows events. UCMDB; Hitachi HiTrack. Twitter.

Scripted connectors

In addition to built-in connectors to common, off-the-shelf systems and applications, Password Manager also includes a number of ﬂexible connectors, each of which is used to script integration with a common protocol or mechanism. These connectors allow organizations to quickly and inexpensively integrate Password Manager with custom and vertical market applications.

There are ﬂexible connectors to script interaction with:

API binding: Terminal Web services: Back end Command-line: emulation: integration: • C, C++ • SSH • SOAP • SQL Injection • Windows • Java, J2EE • Telnet • REST • LDAP • Power Shell • .NET • TN3270, • Pure HTTP(S) attributes • Unix/Linux • COM, ActiveX TN5250 • MQ Series • Simulated browser

Organizations that wish to develop a completely new connector to integrate with a custom or vertical market application may do so using whatever development environment they prefer (Python, J2EE, .NET, etc.) and invoke it as either a command-line program or web service.

If an organization develops their own integrations, an effort of between four hours and four days is typical. Alternately, Hitachi ID Systems offers ﬁxed-cost custom integrations for a nominal fee.

500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 E-Mail: [email protected] hitachi-id.com Date: 2016-01-08 | 2020-07-23 File: /pub/wp/documents/white/hipm/hipm-white-28.tex