Page 1

Securing Embedded Passwords

with Hitachi ID Privileged Access Manager

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


Contents 1 Introduction

1

2 Basic network architecture

1

3 Password randomization and vaulting

2

4 Push and pull

2

5 A circular problem: authenticating to the credential vault

4

6 One time passwords and network address controls

4

7 Technical complications: key management and serialization

5

8 A client-side wrapper library

6

9 Implementation approach

7

10 Summary

8

i


Securing Embedded Passwords with Hitachi ID Privileged Access Manager

1 Introduction Applications often need to connect to other applications or services on the network to function. For example, a web application may have to connect to one or more databases to retrieve or update data, to web services to initiate transactions, to a directory to create or update user objects, etc. When an application connects to a network service, it uses credentials – normally an ID and password – to do so. This raises some questions about password management: 1. Where is the password used by an application to sign into a network service stored? 2. Does the password ever change? 3. How is the stored password protected against compromise? A privileged access management system must be able to address these questions.

2 Basic network architecture The basic arrangement where an application needs to authenticate a connection to a network service is illustrated in Figure 1

Script or Application

Application ID + Password Native protocol of the service -possibly secure

Local or Network Service

ID + Password

Security Database

Config file or embedded

Figure 1: Application to network service authentication The problems of managing and securing these connection credentials are illustrated in Figure 2. In short, these passwords are often plaintext, visible to many (IT or other) users and static.

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

1


Securing Embedded Passwords with Hitachi ID Privileged Access Manager

Script or Application

ID + Password Config file or embedded

Application ID + Password Native protocol of the service -possibly secure

Plaintext? Static? Well known?

Local or Network Service

Security Database

Figure 2: Security problems with embedded credential management

3 Password randomization and vaulting The first and simplest problem to resolve is to periodically change passwords on accounts used to connect to network services. This eliminates at least the static part of the problem. A new service is introduced on the network, charged with periodic password changes and with storing current password values. Applications needing a password to connect to another network service must first retrieve this password from the credential vault. This arrangement, with password randomization, vaulting and fetch-on-demand is illustrated in Figure 3.

4 Push and pull For those applications that can be modified to retrieve credentials when required, the most secure strategy is to modify the application such that it no longer has its own, private, possibly plaintext password storage. Instead, the application should fetch those passwords it requires, only when it needs them. Hitachi ID Systems refers to this as "pulling" credentials from the vault – which should happen only when required. Pull mode is only feasible when the application in question can be modified to use integrate with a secure credential vault. In many cases, an application cannot be modified. It may be a commercial product whose source code is not available and whose vendor is unable or unwilling to integrate it with a vault. In these cases there are two possibilities: 1. There is a way to inject new passwords into the application’s configuration. Hitachi ID Systems refers to this as "pushing" credentials from the vault into the application. While credentials in such applications can be automatically, periodically changed, additional cryptographic protections cannot be provided. Š 2014 Hitachi ID Systems, Inc.. All rights reserved.

2


Securing Embedded Passwords with Privileged Access Manager

Script or Application

(3) Application ID + Password

Local or Network Service

Native protocol of the service -possibly secure

(1) Login

(2) Retrieve password

Periodically randomize passwords

Privileged Access Manager

Security Database

Encrypted Replicated Audited Access controlled Authenticated Credential Vault

Figure 3: Randomizing, vaulting and fetching passwords on demand 2. There is no way to inject new passwords into the application’s configuration. Credential management in such applications cannot be secured at all. In short, there are three scenarios for applications that use embedded passwords to authenticate to services: Application pattern

Vault integration

Security impact

Open, source code available, can be changed.

Pull credentials at runtime.

Best case for protecting embedded passwords.

Closed, code cannot be changed but credentials can be injected.

Push new credentials into configuration whenever password used to connect to a service is changed.

Eliminate static passwords, but passwords may still be plaintext.

Closed, code cannot be changed and credentials cannot modified programmatically.

No automated integration possible. At best, coordinate password changes with a human operator.

Least secure – infrequent password changes, likely plaintext password storage.

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

3


Securing Embedded Passwords with Hitachi ID Privileged Access Manager

The remainder of this document will focus on the most secure, "pull mode" integration, where passwords are retrieved from the credential vault on demand.

5 A circular problem: authenticating to the credential vault The arrangement in Figure 3 seems like a good solution, but it’s actually a circular problem: How does the application authenticate when connecting to the vault? If it is using a password, then we have merely moved the problem around, but not actually solved it. This turns out to be a very difficult problem to resolve. There is really no way to address this problem perfectly: 1. Using PKI (certificates, asymmetric encryption) sounds good, but both the private key and the password which unlocks it need to be available to the application, so this does not solve anything. 2. Asking the operating system hosting the application to fetch keys also sounds good, but there is no magic feature in the OS to protect keys – the OS has the same problem to solve. 3. Binding to the password vault service with SAML, Kerberos or another assertion also sounds good, but how is that initial trust relationship established? Again, an ID and (static? plaintext?) password.

6 One time passwords and network address controls Given the circular problem above. how can the credential vault authenticate that it is an authorized application and not an impostor requesting a given credential? There is no way to make this process perfectly secure, but two techniques can be used to make an attacker’s job much more difficult: 1. Authenticate the application using a one time password – essentially a long, pseudo-random string which is only valid once and is replaced with a new string after each successful authentication. 2. Verify that the application connects to the vault from a known, approved IP address range. This process is illustrated in Figure 4.

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

4


Securing Embedded Passwords with Hitachi ID Privileged Access Manager

(1) Login ID, password (2) Verify IP

Script or Application

(3) Password for next time

Privileged Access Manager

(4) Request password (5) Password value (6) Logout

Credential Vault

Communication is SOAP over HTTPS

Figure 4: One time passwords and IP address checks

7 Technical complications: key management and serialization The process described above improves the confidence that the the credential has that its caller is a valid, authorized application but it places new burdens on the calling application: 1. Where should the one time password (OTP) be stored? 2. How can the OTP be protected? 3. Calls to the credential vault must be serialized, so that there is exactly one sequence of OTP values. If we allow two threads in the client application to sign into the credential vault simultaneously, one of them will store a "new" OTP first and the other one will store the "new" OTP second, but the final OTP value stored may not actually be the most recent and all subsequent authentication will fail. There are other issues that the application must resolve, not related to OTP management: 1. Scalability: What happens if there are many applications, all requesting credentials from the same vault at around the same time? Can the vault respond quickly enough? 2. Availability: What happens if the vault system is temporarily unavailable? Does this create service interruption in the applications that rely on it for credentials needed to sign into services? In short, while the OTP and IP address validation techniques described above are useful at the level of a credential vault remote API, they do not stand alone. The application must incorporate additional logic to perform securely, reliably and with good scalability.

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

5


Securing Embedded Passwords with Privileged Access Manager

8 A client-side wrapper library To address each of the problems described above, a client-side library is required, which wraps around the vault API but also provides essential services: 1. Generating an encryption key, locally. 2. Encrypting local storage of the OTP. 3. Encrypting and caching passwords retrieved from the vault, so that a call to the vault need not be made every time the application requires a password. 4. Serializing calls to the credential vault, to ensure a consistent OTP value. 5. Managing cache semantics (time to live, fetching uncached passwords on demand). 6. Simplifying the calling semantics of for the application. Hitachi ID Privileged Access Manager includes just such a "wrapper" library, available on Windows and Linux systems and callable from the command-line, .NET applications and Java applications. This library can: 1. Compute an encryption key, used to protect local OTP storage and cached passwords, based on: (a) Hostname. (b) IP and MAC addresses. (c) Checksums of the application calling the library. (d) Checksums of other files. (e) Checksums of command line used to run the program. (f) The user ID used to run the application. These mechanisms enable IT security to restrict the circumstances in which a given password is available. For example, if an application is moved to a new server, or modified, or run with different arguments, human intervention will be required to re-enable it to connect to network services. 2. Serialize attempts to sign into the Privileged Access Manager web services API and retrieve new passwords. 3. Cache passwords for a defined time interval (maximum cache time to live defined locally, remaining time before a scheduled password change indicated by Privileged Access Manager). Operation of this wrapper library is illustrated in Figure 5.

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

6


Securing Embedded Passwords with Privileged Access Manager

Script or Application Simplified interface

Application ID + Password

Local or Network Service

Native protocol of the service -possibly secure

API Wrapper Library SOAP (complex): Login, Periodically Update OTP, randomize Fetch PW passwords

Cached password, OTP

Privileged Access Manager

Security Database

Encrypted Replicated Audited Access controlled Authenticated Credential Vault

Figure 5: Credential vault client-side API wrapper library

9 Implementation approach Replacing embedded passwords with calls to a secure credential vault, which in turn regularly changes passwords, is something that has to be implemented for one credential at a time. The process is as follows: 1. Configure a managed system on Hitachi ID Privileged Access Manager for the network service. 2. Configure a managed account on Privileged Access Manager for the credential in question. 3. Schedule regular password changes for the credential in question, ideally on days and at times which are relatively quiet for the application in question. 4. Create one API user (that can sign into Privileged Access Manager) for each instance of the application which will require access to the credential. 5. Create a user group that includes all of the above API users. 6. Assign rights to the above user group, enabling its members to retrieve the password for the account in question. 7. Install the API wrapper library on each server running the application.

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

7


Securing Embedded Passwords with Hitachi ID Privileged Access Manager

8. Edit a configuration file on each server, instructing the library where to find Privileged Access Manager on the network (its HTTPS URL), what user ID to use to connect to the Privileged Access Manager API, how to compute an encryption key and what the initial OTP value is. 9. Modify the application, on each server, to call the API wrapper library when a vaulted password is required. Include a code path to request an uncached password in the event that authentication to the service in question fails. 10. Trigger password randomization for the account in question via the Privileged Access Manager web UI, so that a password value is now available in the vault. 11. Test the application, to ensure that it is able to retrieve passwords on demand. 12. Introduce a network fault between the application and Privileged Access Manager and retest, to ensure that the application continues to function even when it cannot contact Privileged Access Manager. 13. Test the application under load, to ensure that serialization and caching are effective and there is no material performance impact.

10 Summary Securing embedded passwords is an important part of a program to secure privileged access generally. Where it is feasible (i.e., on applications that can be modified to retrieve passwords on demand), the security profile of applications can be significantly improved. Hitachi ID Privileged Access Manager includes a robust infrastructure for securing such credentials but implementation is necessarily one application at a time.

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

www.Hitachi-ID.com

File: / pub/ wp/ documents/ secure-embedded-passwords/ secure-embedded-passw Date: 2014-02-20

Secure embedded passwords  

Applications often need to connect to other applications or services on the network to function. For example, a web application may have to...

Read more
Read more
Similar to
Popular now
Just for you