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.
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.
"One way" encryption techniques are not applicable; DirMaint wou ld
need to be capable of decrypting the passwords before issuing the
DIRECTXA command.
"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".
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.
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.
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.
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.
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.
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.
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.
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.)
