 |
The Question is:
Folks,
I understand that OpenVMS Passwords through V7.2 are limited to letters,
numbers, dollar signs ($) and underscores (_). Has any consideration been
given to expanding the valid character set? If so, when this might become
available?
Thank you,
--Bryan Webb
Pittsburgh Supercomputing Center
Carnegie Mellon University
The Answer is :
Most any password-based mechanism is inherently somewhat insecure in
typical modern computing environments, as a wide variety of attacks
are known and are available -- attacks ranging from simple social
engineering as has been the case in various high-profile computer
security cases, to attacks based on dictionary-based or poor user
password choices, to attacks requiring physical snooping or various
forms of electronic eavesdropping. Other non-traditional attacks
on your internal network and systems are also quite possible (on
most any platform), and these can completely bypass your existing
firewalls and even potentially your existing host-based security.
Attempting to use longer passwords or moving to broader password
character sets will not avoid the problems that are inherent in
traditional password-based authentication schemes. (And in
practice, having more complex or computer-generated passwords can
actually increase certain exposures -- more than a few folks will
write down these hard-to-remember passwords, and physical access
to a desk drawer or to a wallet can result in some rather obvious
security problems.)
The existing OpenVMS password scheme is based on a Purdy polynomial
password-hashing mechanism, and this hashing scheme is inherently
rather difficult to reverse. That said, it is possible that another
unrelated password can be found that hashes down to the same results
as the "correct" password -- this potential for duplicated results
is inherent in any scheme based on hashing. And it is also possible
that an ill-chosen, shared, or (un)intentionally exposed password can
render the system itself insecure.
Good user-to-user and user-to-data security (find your critical data
and/or processes and secure that first), as well as mechanisms such
as bi-directional network firewalls, as well as good system and network
security monitoring and management, as well as having good, simple, and
effective security tools and policies, and user security training, are
all central to maintaining the privacy and integrity of the critical
data.
Although there are obviously limits on any existing user authentication
scheme -- including the OpenVMS password authentication scheme -- there
exists a mechanism which allows OpenVMS to be customised to implement
most any authentication scheme desired.
Further, work on what is known as the ACME programming interface and
support for external authentication is presently underway within
OpenVMS Engineering, and the ACME interface is intended to more
easily and seamlessly permit connections to most any external
authentication scheme available, including Kerberos, smart cards,
and interfacing with biometric hardware. The first part of the ACME
interface was released in V7.1 with the LAN Manager external
authentication, the second with the Kerberos support expected in the
OpenVMS V7.3 release, and further work and enhancements are expected
for inclusion in releases after V7.3.
For details on the existing support for LOGINOUT customization (the
API available prior to full ACME support), please see the OpenVMS
Utility Routines Manual, Chapter 12 LOGINOUT (LGI) Routines. For
details on the Kerberos support in the OpenVMS V7.3 release, please
see the documentation for that release -- as of this writing, the
OpenVMS V7.3 release is just entering external field test.
|
|
|
|
|
