Previous PDF

swipe to navigate


Managing Lotus Notes ID file passwords presents some unique and complex challenges. This document provides an overview of these challenges, and the various ways in which they can be addressed using Hitachi ID Password Manager.

Further information can be found in the full "Password Manager Installation and Configuration Guide."

The Challenge


Lotus Notes Key Escrow

One solution offered by IBM/Lotus to resolve problems that arise when users forget their own passwords is key escrow. Key escrow was introduced with Lotus Notes R5, and works as follows:

  • Setup and initial registration:
    • A recovery database is created, to hold a copy of each user's ID.
    • Recovery IDs are created in that database. These IDs will later be able to, singly or jointly, recover individual users' lost or disabled Notes ID files.
    • The recovery IDs are attached to each certifier ID.
    • Users are sent an e-mail request to "accept" the recovery information into their ID files, and to enable harvesting, which will place a copy of their ID file in the recovery database.

  • Unlocking an ID file when users forget their password:
    • One or more recovery administrators access the user's ID file from the recovery database, and use their own ID files and passwords to generate a recovery password.
    • The recovery password is given to the user.
    • The user types the recovery password, and is able to open the ID file.

ID file recovery does work, but has serious operational problems:

  • It depends on user acceptance and successful registration.

    Unregistered users will not be supported by the process. Users must take several steps to register, and in some cases even users who wish to cooperate (by accepting the recovery message and enabling harvesting) will fail to perform these steps correctly.

  • It is tied to one or more recovery IDs. If these IDs are tied to human administrators, and those administrators leave without providing their password, then the entire registration database becomes obsolete, and the process must be started from scratch.

  • There is no audit trail of ID file recovery. If an administrator can get a copy of a user's ID file, especially without using the recovery database (which can be configured to log access attempts), then the administrator will be able to "recover" the ID and perform actions as the user in question -- effectively impersonating that user.

  • Recovery passwords are, in effect, static passwords applied to each enrolled ID file. They are hard to guess (16 random hexadecimal digits), but once revealed to a user, manager or administrator, they can be thought of as a legitimate password to the user's ID file, which never changes. Static passwords violate security policy in most organizations.

Previous Next PDF