Updated: 11 December 1998 |
OpenVMS Guide to System Security
Previous | Contents | Index |
The console terminal controls operation of the CPU and, consequently, operation of the system. Sites with high security requirements should consider using the password security feature when it is available. (Certain VAXstation 3100s and later models offer it.)
Once the console password is enabled, operators must enter it before using any privileged command in console mode. Privileged commands include the following two types:
To enable the console password feature, take the following steps:
>>> SET PSWD |
1 >>> |
2 >>> |
>>> SET PSE 1 |
To place the workstation in privileged mode and make all console commands accessible, use the LOGIN command. The SHOW PSE command displays the current status of the password feature. (If a 1 is displayed, the feature is enabled; a 0 indicates it is disabled.) To disable the feature, use the SET PSE command with a 0 argument.
Because the password is stored in nonvolatile memory, you must call the
Customer Support Center if you forget it.
7.3.1.5 Authentication Cards
Rather than distribute passwords and account information, some sites choose to provide system users with hand-held devices called authentication cards or smart tokens.
Authentication devices have the user's password programmed onto them.
Depending on the complexity of the hardware design, these devices can
support additional login information (for example, an account name and
billing reference number). A variety of authentication devices are
available from third-party vendors. Such devices are supported by a
software module that communicates with the login program
(LOGINOUT.EXE). See the OpenVMS Utility Routines Manual for a description of the LOGINOUT
routines supporting authentication cards.
7.3.2 Enforcing Minimum Password Standards
You can use AUTHORIZE to impose minimum password standards for
individual users. Specifically, qualifiers and login flags provided by
AUTHORIZE control how soon passwords will expire, whether the user is
forced to change passwords at expiration, and the minimum password
length.
7.3.2.1 Expiring Passwords
With the AUTHORIZE qualifier /PWDLIFETIME, you can establish the maximum length of time that can elapse before the user is forced to change the password or lose access to the account. By default, the value of /PWDLIFETIME is 90 days. You can change the frequency requirements for user password changes by specifying a different delta time value for the qualifier. For example, to require a user to change the password every 30 days, you would specify the qualifier as /PWDLIFETIME=30-0.
The /PWDLIFETIME qualifier applies to both primary and secondary user passwords but not to the system password. Each primary and secondary password for a user is subject to the same maximum lifetime. However, the passwords can change at separate times. As soon as the user completes a password change, that individual password's clock is reset; the new password value can exist unchanged for the length of time dictated by /PWDLIFETIME.
AUTHORIZE also provides two login flags related to primary and secondary password expiration. These flags, PWD_EXPIRED and PWD2_EXPIRED, are specified with the /FLAGS qualifier. The first flag, PWD_EXPIRED, is set after the primary password expires and the user has had one last chance to change the password and has failed to do so. The second flag, PWD2_EXPIRED, is set after the secondary password expires and the user has had one last chance to change the secondary password and has failed to do so. If either PWD_EXPIRED or PWD2_EXPIRED is set, the account is disabled for logins because the user failed to employ the last chance to change the password during the last login.
As soon as the user successfully changes the password, the system resets the flags, as appropriate. The flag PWD_EXPIRED becomes NOPWD_EXPIRED as soon as the primary password is changed. Similarly, the flag PWD2_EXPIRED becomes NOPWD2_EXPIRED as soon as the secondary password is changed. As security administrator, you may choose to invoke AUTHORIZE and reset the flags, giving the user another chance to reset the password.
The use of a password lifetime forces the user to change passwords regularly. The lifetime can be different for different users. Users with access to critical files generally should have the shortest password lifetimes.
System passwords have an unlimited lifetime. It is your responsibility as security administrator to change the system password regularly.
SYS$PASSWORD_HISTORY_LIFETIME should be made larger than the UAF parameter PWDLIFETIME. If you set the SYS$PASSWORD_HISTORY_LIFETIME value to less than PWDLIFETIME, passwords will expire out of the history file before they expire in SYSUAF. This defeats the purpose of the password history file. For more information about PWDLIFETIME parameter, see Section 7.3.2.2. |
By default, users are forced to change expired passwords when logging in. Users whose passwords have expired are prompted for new passwords at login. This password feature is valid only when a password expiration date is specified with the /PWDLIFETIME qualifier.
To disable forced password changes, specify the following qualifier to the ADD or the MODIFY command:
/FLAGS=DISFORCE_PWD_CHANGE |
Once you disable the forced password feature, you can reenable it by clearing the login flag, as shown in the following:
/FLAGS=NODISFORCE_PWD_CHANGE |
Users who log in and are prompted to change expired passwords can cancel the login by pressing Ctrl/Y.
If secondary passwords are in effect and both primary and secondary passwords have expired, the user is forced to change both passwords. If the user changes the primary password and presses Ctrl/Y before changing the secondary password, the user is logged out, and no password change is recorded. |
With the AUTHORIZE qualifier /PWDMINIMUM, you can direct that all password choices, both primary and secondary, must contain a minimum number of characters. (Users can still specify passwords up to the maximum length of 32 characters.)
A user's minimum password length is either the default of 6 characters or another value established by the /PWDMINIMUM qualifier (provided the number is 10 or less).
On Alpha systems, the password generator creates passwords of the exact length specified but limited to 10 characters.
On VAX systems, the password generator creates passwords that range in length between n and n+2, where the minimum length n is a value ranging from 1 to 10. So the length of a generated password (/GENERATE_PASSWORD or SET PASSWORD/GENERATE) can conflict with the value provided with the /PWDMINIMUM qualifier.
When there is a conflict between n and the value set by the /PWDMINIMUM qualifier, the operating system uses the lesser value, but never more than 10. For example, if you specify a length of 25 with the /PWDMINIMUM qualifier, the operating system generates passwords of 10 to 12 characters. The system does not notify you of the difference in values.
The length of a generated password produced by the AUTHORIZE qualifier /GENERATE_PASSWORD comes from the Pwdminimum field of the source UAF record: the DEFAULT record or the UAF record copied. The Pwdminimum field is updated with the value set by /PWDMINIMUM, so passwords created with SET PASSWORD/GENERATE use the new value.
The system password is not subject to a minimum length. Guidelines that
apply to user passwords are equally applicable to system passwords.
Choose system passwords that are 1 to 32 characters long.
7.3.2.4 Generated Passwords
The /FLAGS=GENPWD qualifier in AUTHORIZE lets you force use of the automatic password generator when a user changes a password. At some sites, all accounts are created with this qualifier. At other sites, the security administrator may be more selective.
If users will have access to sensitive data that must not be compromised by an intrusion, require them to use the password generator.
If your policy is to request voluntary use of the password generator
and users are not cooperating, you can force users to use the password
generator by adding the /FLAGS=GENPWD qualifier to pertinent user
accounts. You can also add the AUTHORIZE qualifier /FLAGS=LOCKPWD to
user accounts to prevent users from changing passwords. Only you will
be authorized to change passwords.
7.3.2.5 Site Password Algorithms
The operating system protects passwords from disclosure through encryption. OpenVMS algorithms transform passwords from plaintext strings into ciphertext, which is then stored in the system user authorization file (SYSUAF.DAT). Whenever a password check is done, the check is based on the encrypted password, not the plaintext password. The system password is always encrypted with an algorithm known to the operating system.
The /ALGORITHM qualifier in AUTHORIZE allows you to define which algorithm the operating system should use to encrypt a user's password. Your choices are the current OpenVMS algorithm or a site-specific algorithm. You can specify the encryption algorithm independently for each account's primary and secondary passwords. The syntax is as follows:
/ALGORITHM=keyword=type [=value] |
To assign the OpenVMS password encryption algorithm for a user, you would enter a command like the following:
UAF> MODIFY HOBBIT/ALGORITHM=PRIMARY=VMS |
If a site-specific algorithm is selected, you must give a value to identify the algorithm, for example:
UAF> MODIFY HOBBIT/ALGORITHM=CURRENT=CUSTOMER=128 |
The OpenVMS Programming Concepts Manual provides directions for using a customer algorithm. You must create a site-specific system service in which you write code that recognizes the algorithm number you choose and encrypts the password appropriately. This number has to correspond with the number used in the AUTHORIZE command MODIFY/ALGORITHM.
Whenever a user is assigned a site-specific algorithm, AUTHORIZE
reports this information in the display provided by the SHOW command.
7.3.3 Screening New Passwords
The system generally compares new passwords against a system dictionary
stored in SYS$LIBRARY to ensure that a password is not a native
language word. It also maintains a history list of a user's passwords
and compares each new password against this list to guarantee that an
old password is not reused. You can screen passwords further by
developing and installing an image that filters passwords for words
that are particularly sensitive to a site.
7.3.3.1 System Dictionary
The DCL command SET PASSWORD takes a user's proposed password, converts it to lowercase (if necessary), and compares it to entries in a system dictionary to ensure that a password is not a native language word. If a proposed password is found in the dictionary, it is rejected as a valid user password, and the user has to provide another.
You may want to modify the system password dictionary to include words of significance to your site. The following procedure lets you add words to the system dictionary. The procedure also lets you retain a file of the passwords that you consider unacceptable.
$ CREATE LOCAL_PASSWORD_DICTIONARY.DATA somefamous localheroes [Ctrl/Z] |
$ SET PROCESS/PRIVILEGE=SYSPRV $ CONVERT/MERGE/PAD LOCAL_PASSWORD_DICTIONARY.DATA - _$ SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA |
You can disable the dictionary search by using AUTHORIZE with the
DISPWDDIC option to the /FLAGS qualifier.
7.3.3.2 History Lists
The operating system maintains a list of a user's passwords from the last 365 days and compares each proposed password against this list to ensure that passwords are not reused.
Once a user successfully creates a new password, the system enters the old password on the history list and updates the file. The password history list can hold a large number of words, but it is limited to 60 by default. If this number is exceeded, the user has to use generated passwords. A password remains on the password history list for 365 days (or the default set by SYS$PASSWORD_HISTORY_LIFETIME). Whenever a user account is deleted, the system removes all password records belonging to that account.
Using the DCL command DEFINE, you can change the defaults for the capacity and lifetime of the password history list to any of the values indicated in Table 7-4.
System Logical Name | Default | Min | Max | Units |
---|---|---|---|---|
SYS$PASSWORD_HISTORY_LIFETIME | 365 | 1 | 28000 | Days |
SYS$PASSWORD_HISTORY_LIMIT | 60 | 1 | 2000 | Absolute count |
$ DEFINE/SYSTEM/EXEC SYS$PASSWORD_HISTORY_LIMIT 100 |
There is a correspondence between the lifetime of a password history list and the number of passwords allowed on the list. For example, if you increase the password history lifetime to 4 years and your passwords expire every 2 weeks, you would need to increase the password history limit to at least 104 (4 years times 26 passwords a year). The password history lifetime and limit can be changed dynamically, but they should be consistent across all nodes on the cluster.
Sites using secondary passwords may need to double the password limit to account for the secondary password storage.
The password history list is located in SYS$SYSTEM. You can move the list off the system disk by using the logical name VMS$PASSWORD_HISTORY. Define this logical name as /SYSTEM/EXEC, and place it in SYS$MANAGER:SYLOGICALS.COM.
You disable the history search with the DISPWDHIS option to the /FLAGS
qualifier in AUTHORIZE.
7.3.3.3 Site-Specific Filters
Besides screening passwords against a system dictionary and a history list, you can develop a site-specific password filter to ensure that passwords are properly constructed and are not words readily associated with your site. A filter can check for password length, the use of special characters or combinations of characters, and the use of product names or personnel names.
To create a list of site-specific words, you write the source code, create a shareable image, install the image, and, finally, enable the policy by setting a system parameter. See the OpenVMS Programming Concepts Manual for instructions.
Installing and enabling a site-specific password filter requires both SYSPRV and CMKRNL privileges. Multiple security alarms are generated when the password filter image is installed if INSTALL and SYSPRV file-access auditing are enabled and the required change to the system parameter is noted on the operator console.
The shareable image contains two global routines that are called by the Set Password utility (SET PASSWORD) whenever a user changes a password.
The two global routines let you obtain both the proposed plaintext password and its equivalent quadword hash value. All security administrators should be aware of this feature because its subversion by a malicious privileged user will compromise the system's security. Compaq recommends that you place security Alarm ACEs on the password filter image and its parent directory. See the OpenVMS Programming Concepts Manual for instructions. |
In addition to all the recommendations included in Section 3.8, observe the following guidelines to protect passwords:
The following actions reduce the potential of password detection or limit the extent of the damage if passwords are discovered or bypassed:
External authentication allows users to log in (or sign on) at the OpenVMS login prompt using their external user IDs and passwords. The PATHWORKS and Advanced Server for OpenVMS authentication modules are supported as external authenticators, providing NT-compatible authentication of OpenVMS users.
When successfully authenticated, the external user ID is mapped to the appropriate OpenVMS user name and the correct user profile is obtained.
By default, external authentication is disabled at both the system and user levels. However, when you invoke PATHWORKS or Advanced Server for OpenVMS, external authentication is automatically enabled.
Before users can log in, the system administrator must enable external authentication by performing the following:
These tasks are discussed in the following sections.
Defining External Authentication Logical Names
At the system level, external authentication is enabled by defining two system-wide executive-mode logical names:
The SYS$SINGLE_SIGNON logical name is automatically defined to 1 (enabled) by PWRK$ACME_STARTUP.COM (the PATHWORKS and Advanced Server for OpenVMS startup procedure) if it has not yet been defined in SYSTARTUP_VMS.COM. If you want to disable external authentication or set the SYS$SINGLE_SIGNON logical name to another value, define SYS$SINGLE_SIGNON in SYSTARTUP_VMS.COM before PATHWORKS or Advanced Server for OpenVMS is started. (See Table 7-5 for more information on the SYS$SINGLE_SIGNON logical name bits.) |
For example:
$ DEFINE/SYSTEM/EXECUTIVE SYS$SINGLE_SIGNON 0 |
Marking User Accounts in the SYSUAF
At the user level, external authentication is enabled by a flag, EXTAUTH, in the SYSUAF record. When set, the EXTAUTH flag denotes that the user is to be externally authenticated. For example, in the Authorize utility, you would enter commands similar to the following:
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD username /FLAGS=([NO]EXTAUTH) UAF> MODIFY username /FLAGS=([NO]EXTAUTH) |
(See the OpenVMS System Management Utilities Reference Manual: A--L for more information on the Authorize utility EXTAUTH flag. See the OpenVMS System Services Reference Manual: GETQUI--Z for more information on the UAI$V_EXTAUTH bit in the SYS$GETUAI and SYS$SETUAI system services UAI$_FLAGS item code.)
Previous | Next | Contents | Index |
Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal |
6346PRO_015.HTML
|