Software Solutions at an Advantage

In contrast, a centralized software-based solution offers a number of advantages: The stored passwords can be accessed by the authorized party at any time and without a media gap; logging and reporting show who was given which passwords and when; and it is easier to modify a stored password digitally than with paper, envelopes, and a central vault.

However, it is precisely this assumed ease of access to the content of a software vault that fuels the concerns of the administrators using it. What happens if someone can simply retrieve all the passwords because of a vulnerability in the vault software? Does capturing a single administrative password mean the attacker can grab the entire database? Such new risks must be considered when implementing centralized password management tools. Of course, the software vendor is also aware of these concerns and can address them in organization-wide centralized solutions.

The desire to be informed reliably whether someone is given access to a password means it's logical for password management to be client-server based: The password management software must be a trusted intermediate layer, which cannot be circumvented by someone, for example, copying the entire password database and using it for their own purposes. This also means that you must be able to trust the administrators of the central password management services and that the functionality of this service must be maintained even under adverse circumstances.

When you take a closer look at the relevant software products, the high-availability/redundancy features are what separate the wheat from the chaff. When considering PSE, for example, it is possible automatically to mirror a database with all your data on a second server.

Guess My Name

Because it is undesirable for all passwords to be viewed by all users of the software, it is necessary to introduce an appropriately granular authorization concept. Many software solutions, including PSE, essentially provide the permission levels "read" and "write," wherein setting both permissions is equivalent to full access.

Often, other permissions govern, for example, printing, deleting, or exporting contacts via a dedicated client software, as well as the authority to assign permissions, as shown in Figure 1. However, one typically desired permission level is often missing: "read and alert." This level also must be implemented in some other way depending on the product and its philosophy.

Figure 1: Managing authorization levels in the PSE system.

This authorization level is crucial for emergency password management. Users who need to access their passwords in an emergency are not entitled to do so in everyday operation. Therefore, "read" would give them too much leeway, contradicting the principle that users should be assigned only minimum rights. The "read and alert" level restricts permissions to the extent that, although read access is still possible at any time, notification is sent to those responsible. To minimize the risk of further abuse, it should be an option to enforce a two-pairs-of-eyes principle for certain password entries or for specific user groups.

Is the Seal Intact?

Formerly, the integrity of a seal indicated whether a message had been opened and thus whether the content had been read by unauthorized persons en route. The same principle is used by some password management systems to make it clear whether passwords have been displayed or used. To do so, you apply a virtual seal to a password entry. The password manager then registers access to the password and only returns the contents of the password entry if the seal is broken by the requester (Figure 2).

Figure 2: Seal-protecting a password entry in PSE.

In password managers with a sophisticated authorization system, such as PSE, you can specify which users are allowed to break the seal or which users are entitled to edit password entries that are under seal protection. This property is an important requirement when a regular password change is required. If this functionality were not present, every password change would mean first breaking the seal to change the password and then reapplying the seal with all its permission levels.

Finally, the question arises as to how much of the password manager's functionality should be deployed on the server system and how much on the users' systems. Approaches range from keeping the database and the authorization check on the server side to examples in which the entire program logic is in the hands of a web application.

Tasks such as securing availability and managing authorizations must be executed on the server side. A client-based implementation of the remaining functionalities makes it easier to customize the behavior of a password management solution, whereas a web application can be used by different operating systems and devices. Examples of possible behavioral adaptation include automatic opening of SSH or RDP connections, without needing to display the password to the user. Client-based solutions generally allow for the creation of individual settings for each user.