HP OpenVMS Guide to System Security: OpenVMS Version 8.4 > Chapter 7 Managing System Access
A site needing average security protection always requires use of passwords. Sites with more security needs frequently impose a generated password scheme (see “Generated Passwords”) and possibly system passwords as well.
With the exception of an automatic login account, all users must have at least one password to log in. Sites with moderate or high security requirements may impose additional passwords (see “Types of Passwords”Table 3-2).
Externally authenticated users enter their external password at the OpenVMS password prompt. See “Enabling External Authentication” for more information.
When you open an account for a new user with AUTHORIZE, you must give the user a user name and an initial password. When you assign temporary initial passwords, observe all guidelines recommended in “Guidelines for Protecting Your Password”"Guidelines for Protecting Your Password" on page 53. Avoid any obvious pattern when you assign passwords. You may want to use the automatic password generator.
To use the automatic password generator while using AUTHORIZE to open an account, add the /GENERATE_PASSWORD qualifier to either the ADD or the COPY command. The system responds by offering you a list of automatically generated password choices. Select one of these passwords, and continue setting up the account.
Passwords you specify with AUTHORIZE are defined as expired by default. This forces the user to change the initial password when first logging in. See “Enforcing Minimum Password Standards” for more information. Be sure to include information on the first login in your user training so that users know what to expect. If you do not want the password you define with AUTHORIZE to be pre-expired, add the qualifier /NOPWDEXPIRED when entering the password. This is necessary for accounts when users are not permitted to set their own password.
“Entering a System Password”"Entering a System Password" on page 43 introduces system passwords, which control access to particular terminals. System passwords are used to control access to terminals that might be targets for unauthorized use, as follows:
To enable the use of the system password for the remote class of logins (those accomplished through the DCL command SET HOST), set the appropriate bit in the default terminal characteristics parameter by using AUTOGEN. This is bit 19 (hexadecimal value 80000) in the parameter TTY_DEFCHAR2. Note that if you set this bit, you must invoke the DCL command SET TERMINAL/NOSYSPWD/PERMANENT to disable system passwords for each terminal where you do not want the feature. (As before, consider placing the SET TERMINAL commands you have tested in SYS$MANAGER:SYSTARTUP_VMS.COM.) Then follow the previously defined steps to set the system password.
When choosing a system password, follow the recommendations presented in “Guidelines for Protecting Your Password”"Guidelines for Protecting Your Password" on page 53. Choose a string of characters and digits, with a minimum length of 6, that is not a valid word. Although the system password is not subject to expiration, change the password frequently. Always change the system password as soon as a person who knows the password leaves the group. Share the system password only with those who need to know.
The system password is stored in a separate UAF record and cannot be displayed. The DCL command SET PASSWORD/SYSTEM (the normal means of setting and changing the system password) requires that you enter the old system password before changing it. Use the AUTHORIZE command MODIFY/SYSTEM_PASSWORD to change the system password without specifying the old password, as shown in the following command:
The primary function of the system password is to form a first line of defense for publicly accessible ports and to prevent potential intruders from learning the identity of the system. However, requiring system passwords can appear confusing when authorized users are unaware that they are required on certain terminals. To avoid false reports of defective terminals or systems, inform your users which terminals allocated for their use require system passwords.
Where system passwords are not applied to either control access through dialup lines or on publicly accessed lines, few people may know the system password. Operations are hampered if the personnel who know the password are unavailable, incapacitated, or forgetful. Solve this problem by invoking AUTHORIZE and entering the MODIFY/SYSTEM_PASSWORD command. SYSPRV privilege is required.
Sites with high-level security concerns can require a second password on user accounts. Typically, the user does not know the secondary password, and a supervisor or other key person must be present to supply it. For certain applications, the supervisor may also decide to remain present while the account is in use. The effectiveness of a secondary password depends on the trustworthiness of the supervisor who supplies it because the supervisor can remove the secondary password by changing it to a null string.
Sites with medium security requirements may use dual passwords as a tool when there are unexplained intrusions after the password has been changed and use of the password generator has been enforced. Select problem accounts, and make them a temporary target of this restriction. If the problem goes away when you institute personal verification through the secondary password, you know you have a personnel problem. Most likely, the authorized user is revealing the password for the account to one or more other users who are abusing the account.
ADD newusername /PASSWORD=(primarypwd, secondarypwd)
MODIFY username /PASSWORD=("", secondarypwd)
This command does not affect the primary password that already exists for the account but adds the requirement that a secondary password be provided at each subsequent login. The secondary password acquires the same password lifetime and minimum length values in effect for the primary password. If the /FLAGS=GENPWD qualifier has been specified for this account, the secondary password can be changed only under the control of the automatic password generator. You cannot use wildcards in the user name parameter to apply a secondary password to multiple users with a single command.
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.)
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.
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 HP OpenVMS Utility Routines Manual for a description of the LOGINOUT routines supporting authentication cards.
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.
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.
The LGI$PASSWORD_NOCHANGE_DAYS and LGI$EXPIRATION_WARNING_DAYS logicals are systemwide, executive-mode logical names.
You can define the LGI$PASSWORD_NOCHANGE_DAYS logical to set the minimum number of days before the user can change the password.
The LGI$EXPIRATION_WARNING_DAYS logical can be defined to set the number of days prior to the expiration of password when the user shall start receiving the password expiration warning messages.
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.
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.)
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 /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 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.
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:
The HP 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.
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.
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.
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 “Defaults for Password History List”.
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.
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.
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 HP 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.
In addition to all the recommendations included in “Guidelines for Protecting Your Password”"Guidelines for Protecting Your Password" on page 53, observe the following guidelines to protect passwords: