Typing in login names and passwords has, for many years, been the most common form of authentication in IT environments with normal protection requirements. Alternatives such as tokens, smart cards, electronic cards, and various types of biometrics have not changed this. There is virtually no alternative to passwords: Low implementation costs, sufficiently high user acceptance, and the relative rarity of significant security incidents suggest that passwords are unlikely to become extinct in the near future.

Emergency password management covers situations in which third parties not directly involved in service operations need access to systems under exceptional circumstances to prevent greater damage. For example, the objective could be for a 24/7 security team to access compromised servers, even if the system administrator is not available.

In Case of Emergency

The classic solution to this problem is a list of passwords in a sealed envelope that is deposited in a vault and handed over when an emergency occurs. Conventional solutions like this, however, do not scale adequately: Now larger organizations and data centers need to deposit not just a handful but dozens or hundreds of passwords, and regular password changes are required not only for password policies based on ISO/IEC 27001 but also, for example, in case of staff changes.

Maintaining a stored list of passwords thus evolves from a subjectively annoying chore to an objective time waster. Migrating emergency password management to a centralized, server-based software solution that can be used from any workstation offers many benefits but also incurs many security risks and needs to be well considered because of its importance.

This article examines the opportunities and risks and derives specific selection criteria for centralized password management products. The practical implementation is discussed using the Leibniz data center (LRZ) as an example. The LRZ is the central IT service provider for Munich universities and colleges; it provides services to approximately 130,000 university staff and students and operates the Munich Scientific Network with around 110,000 devices.

To manage the mass of passwords for servers and services operated at the LRZ, the commercial password manager Password Safe Enterprise Edition (PSE) by Mateso [1] was introduced. PSE quite elegantly meets many requirements but also has some weaknesses, which we hope will be fixed in future versions.

Why Centralized Password Management?

Although many regular users are rather careless with their passwords  – think of the infamous yellow sticky notes on monitors – most administrators take care to uphold their secrecy. Many admins would prefer not to share passwords with others and manage them exclusively offline, for example, using a password list on a piece of paper that they carry around in a wallet or lock away in some item of office furniture.

With some effort, both the number of passwords to manage and the need to share passwords can be minimized. For example, SSH keypairs replace passwords for authentication in remote login scenarios on Linux servers. Personal, non-administrative identifiers in combination with the use of sudo on Linux, or UAC on Windows, make shared knowledge of the root or administrator password unnecessary.

The problem of how to define emergency passwords still persists; every organization wants to continue managing its servers even if the usual administrator is not available. Added to that is the necessity of password-sharing for services that do not support role authorization models with multiple administrators.

Many administrators use personal password management tools like KeePass [2] or KeePassX [3], where all of their passwords are stored in a file and encrypted with a personal master password, so that no one else can access it. With this approach, passwords can be easily entered via copy and paste, which avoids the media gap resulting from writing passwords on paper. Many tools also directly start an SSH or RDP connection with automatic password entry; the process is thus similar to storing passwords in a web browser.

Doubts About a Central Control Center

When it comes to depositing passwords centrally in an organization-wide database, there is often much skepticism, and it is not entirely unjustified. Offline variants, such as the password list in a sealed envelope in a vault, are still often well accepted. In practice, however, the vault solution has many disadvantages. For example, it cannot readily be known who has viewed which password; even complete password lists may have been copied.

Another question is whether the normal administrator has been notified of access to his or her password and with what kind of delay. Additionally, access is only possible to the vault if the key owner is available, which is not always the case and ultimately only shifts the administrator's problem. And, if passwords must be changed regularly, the vault simply becomes a paper file, thereby adding administrative overhead.