DirMaint Source Directory Encryption

Last updated: 1999-02-08     (Subscribe to updates)

Passwords are stored in the clear within the source directory. Should these somehow be encrypted?

The native support available with CP and DirMaint do not provide the capability to maintain either the entire directory or the user passwords within in encrypted format. Any implementation of this capability would require modifications to DirMaint, or to both CP and DirMaint.

The following are reasons why it is unnecessary to encrypt the passwords within the source directory.

  1. Support within DirMaint would provide only a false sense of security at the expense of at least some performance impact. The DirMaint server would need to manage the encryption keys, and would need to store the key on disk for later use.
    1. "One way" encryption techniques are not applicable; DirMaint wou ld need to be capable of decrypting the passwords before issuing the DIRECTXA command.
    2. "Bidirectional" encryption would be ineffective; since the code to generate and manage the key(s), and the code to perform both the encryption and the decryption would all be available to a single user who had access to the DIRMAINT machine's disks.
    A more effective technique to protect against unauthorized disclosure in these circumstances is that of "access control".

  2. It would be possible to design a local modification to both CP and DirMaint that would exploit one-way encryption of the passwords. However, this is part of what IBM's external security manager (Resource Access Control Facility, RACF) provides. The password in the directory is no longer used, and is owned by the ESM, and the ESM owned password is one-way encrypted. Many ESMs provided by vendors also take over ownership of the logon passwords and the directory passwords are generally not used.

  3. Under "normal circumstances", the ESM (whether RACF or otherwise) "owns" the user's logon password (whether or not it is encrypted). Disclosure of the "password" in the CP directory poses no exposure for unauthorized access as long as:
    • the ESM is up and operational; and
    • the password in the CP directory is DIFFERENT than the password in use through the ESM.
    For maximum assurance, the CP directory passwords should be set to a randomly generated value. DirMaint's PWGEN capability can accomplish this.

  4. Under "abnormal circumstances", when the ESM is not operational; it is necessary to make use of the CP directory password for certain key user ID's in order to repair your system. These ids are usually the OPERATOR, MAINT, DIRMAINT, the ESM server, a BACKUP/RESTORE server, and possibly an SFS server. These user ID's should be restricted to use only by trusted personnel from secure locations. And anytime the ESM is not operational, the operator should DISABLE access to terminal lines, and stop remote access by means of PVM, SNA, TCP/IP, etc.

  5. It is necessary to pay attention to those user ID's that have direct or indirect access to data (whether the CP directory or otherwise).
    • Who has a directory link to the disk in question?
    • Who has a full volume minidisk that overlaps the disk in question?
    • Who is permitted to access disks in either of these categories? Is this access still justified?
    • Who has access to the backup tapes for the minidisk or real disk volume in question?
    Many security incidents are more likely to be caused by failure to exercise proper disk access control than by exposure of logon passwords in the CP source directory.

  6. A somewhat greater exposure is presented by careless users, such as those who write their password on a piece of paper and carry it in their wallet or purse and then lose the wallet or purse, or who keep the paper in an unlocked desk drawer, or write it on the back page of the calendar near their terminal, etc.

  7. Another large exposure is from users who do almost everything they can to minimize password security. If short passwords such as ABC are prohibited, the result is a lot of ABCDEF's. If numbers are required, you will see ABC123s. If you prohibit use of consecutive letters and numbers, you will see A2C4E6Gs. Even more prevalent in the published reports and my own observations are people who pick the names of their significant other, their brand of car (or the car they wish they had), the name of their favorite sports team, their ham radio call sign, their car license plate number, their dog's name, etc.

  8. VM/SP release 5 + RACF 1.8.2 + DirMaint 1.4.0 + VMTAPE (*) was successfully evaluated as a class C2 Trusted Computing Base by the Department of Defense, and several releases of VM/ESA Version 1 were submitted for evaluation against both the C2 and B1 criteria, as documented in DoD publication 5200.28-STD dated December 1985. While VM/ESA version 2 has not been submitted for formal evaluation by the DoD, it remains designed to meet the C2/B1 TCB criteria. Neither the completed evaluation of VM/SP release 5 nor the partial evaluations of VM/ESA version 1 raised a concern with the contents of the VM source directory not being encrypted.

    Note: VMTAPE was a product of then VM Software Inc., now Sterling Software Inc.

  9. While no longer part of the VM/ESA library, the publications that document how to configure and use VM/ESA in a designed to meet TCB environment may still be available.
    • SC23-0533-01 DirMaint R4 Security Considerations
      (Make sure you explicitly order the -01 edition. The -02 edition is a completely different publication for DirMaint R5.)
    • SC24-5563-00 VM/ESA with RACF: Trusted Facility Manual
    • SC24-5564-00 VM/ESA with RACF: Security Features User's Guide


If you'd like to contact DirMaint development and support, you can

Thank you for visiting this web page. Please visit again next month and check out the latest news. (Or, subscribe to future updates.)