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
This section describes password management.
Types of Passwords
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).
This section explains how to assign passwords
using DCL and AUTHORIZE commands.
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.
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.
NOTE: There are restrictions on using the /GENERATE_PASSWORD
qualifier with the /PWDMINIMUM qualifier. Generated passwords have
an absolute length of 12 characters (see “Requiring a Minimum Password Length”). Whenever there is a conflict between
the value of /PWDMINIMUM and a generated password, the operating system
uses the lesser of the two values.
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.
Pre-expired passwords are conspicuous in the UAF
record listing. The entry for the date of the last password change
carries the following notation:
“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:
All terminals using dialup
lines or public data networks for access
Terminals on lines that
are publicly accessible and not tightly secured, such as those in
computer laboratories at universities
Terminals not frequently
Terminals intended for
use only as spare devices
Terminals you want to
reserve for security operations
Execute the following steps to implement system passwords:
Establish a record in
the SYSUAF database for a system password by invoking the Authorize
utility and entering the following command:
NOTE: You need to establish a record in the SYSUAF database
only the first time a system password is set up on the system. However,
if no record is present,the SET PASSWORD/SYSTEM command returns the
%SET-F-UAFERR, error accessing authorization file
-RMS-E-RNF, record not found
Decide which terminals
require system passwords. Then, for each terminal, enter the DCL command
SET TERMINAL/SYSPWD/PERMANENT. When you are satisified that you have
selected the right terminals, incorporate these commands into SYS$MANAGER:SYSTARTUP_VMS.COM
so that the terminal setup work is done automatically at system startup.
You can remove the restriction on a terminal at any time by invoking
the DCL command SET TERMINAL/NOSYSPWD/PERMANENT for that terminal.
Choose a system password,
and implement it with the DCL command SET PASSWORD/SYSTEM, which requires
the SECURITY privilege. This command prompts you for the password
and then prompts you again for verification, just as for user passwords.
To request automatic password generation, include the /GENERATE qualifier.
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.
Although the use of dual passwords is cumbersome,
they do offer the following advantages:
When used on a widespread
basis, dual passwords help verify the identity of each user at login
time because the supervisor or other key person can check each user.
When used in limited cases,
dual passwords single out accounts that can be logged in to only when
two persons are present.
Dual passwords also prevent
the use of access control strings when users access accounts through
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
Implement dual passwords with the AUTHORIZE qualifier
/PASSWORD. For example, to impose dual passwords on a new account,
invoke AUTHORIZE and use the following form of the ADD command:
To impose a secondary password on an existing
account, use the following form of the MODIFY command:
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.
NOTE: While you
can specify secondary passwords for accounts requiring remote access
through the DCL command SET HOST, you cannot specify them for accounts
requiring network file access using access control strings. If an
account with a secondary password is to be used for network access
(for example, remote file access), you must set up proxy access for
all remote nodes from which the account may be accessed.
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
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:
Commands that examine
or modify memory and registers, such as SET, EXAMINE, DEPOSIT, FIND,
Commands that transfer
control of the CPU from the console monitor to another program, such
as BOOT and START. (Invoking the default boot, which requires a BOOT
command with no parameters, is not a privileged command and is allowed
without the password.)
To enable the console password feature, take the
Enter the privileged command:
In response, the console
prompts for a password:
Enter the new password, and press the Return key.
Note that the console does not display the password as you enter it.
The password must be a hexadecimal string of characters
(0 through 9 and A through F) with a length of exactly 16 characters.
If the password character
string is of the right length, the console prompts for you to reenter
the new password for verification:
Reenter the new password, and press Return. Again,
note that the password is not displayed.
Enable the password security
feature with the following command:
>>>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.
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 HP OpenVMS
Utility Routines Manual for a description of the LOGINOUT
routines supporting authentication cards.
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.
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
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.
The qualifier /NOPWDLIFETIME specifies that primary
and secondary passwords do not expire.
NOTE: Specifying /NOPWDLIFETIME removes the default
behavior that initial passwords be reset. However, if you want to
have initial passwords reset but you do not want password expiration,
you can specify /PWDLIFETIME="9999-".
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
NOTE: SYS$PASSWORD_HISTORY_LIFETIME must be 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 “Enforcing Change of Expired Password”.
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 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
Enforcing Change of Expired Password
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:
Once you disable the forced password feature,
you can re-enable it by clearing the login flag, as shown in the following:
Users who log in and are prompted to change expired
passwords can cancel the login by pressing Ctrl/Y.
NOTE: 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.
Requiring a Minimum Password Length
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
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
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.
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
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:
To assign the OpenVMS password encryption algorithm
for a user, you would enter a command like the following:
If a site-specific algorithm is selected, you
must give a value to identify the algorithm, for example:
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.
Whenever a user is assigned a site-specific algorithm,
AUTHORIZE reports this information in the display provided by the
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.
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 a file containing
passwords you would like to add to the dictionary. Each password should
be on a separate line and in lowercase, as follows:
You can disable the dictionary search by using
AUTHORIZE with the DISPWDDIC option to the /FLAGS qualifier.
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 “Defaults for Password History List”.
Table 7-4 Defaults for Password History List
System Logical Name
For example, to increase the capacity of the history
list from 60 passwords to 100, add the following line to the command
procedure SYLOGICALS.COM, which is located in SYS$MANAGER:
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.
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.
The shareable image contains two global routines
that are called by the Set Password utility (SET PASSWORD) whenever
a user changes a password.
CAUTION: 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
HP recommends that you place security Alarm ACEs
on the password filter image and its parent directory. See the OpenVMS
Programming Concepts for instructions.
Make certain the passwords
on the standard accounts like SYSTEM are secure and changed regularly.
You can disable accounts (for example, FIELD and SYSTEST) with the
AUTHORIZE qualifier /FLAGS=DISUSER when they are not in use.
Do not permit an outside
or in-house service organization to dictate the password for an account
they use to service your system. Such service groups tend to use the
same password on all systems, and their accounts are usually privileged.
On seldom-used accounts,
set the AUTHORIZE qualifier /FLAGS=DISUSER, and enable the account
only when it is needed. Change the password immediately after each
use, and notify the service group of the new password when they need
Delete accounts no longer
Do not leave listings
of user names where they can be read or stolen because they can be
used as a basis for system attack. (If you do need listing files,
use ACLs to limit access only to selected individuals.)
Maintain adequate protection
of authorization files. Note that the system user authorization file
(SYSUAF.DAT), the network proxy authorization file (NETPROXY.DAT),
and the rights list (RIGHTSLIST.DAT) are owned by the system account
([SYSTEM]). Do not create any other user accounts in this group. Normally
the default UIC-based file protection for these authorization files
is adequate. The system account also owns the file NET$PROXY.DAT.
Make certain that all
users have unique UICs.
The following actions reduce the potential of
password detection or limit the extent of the damage if passwords
are discovered or bypassed:
Avoid giving multiple
users access to the same account.
Protect telephone numbers
for dialup lines connected to your system, and consider setting a
system password (SET TERMINAL/SYSPASSWORD) on dialup lines.
If your system has accounts
available to outside users, such as guest accounts or accounts for
direct customer inquiry, make these accounts captive (limited-access)
accounts contained by captive command procedures. (See “Captive Accounts” for information about setting up captive accounts.)
Make captive all accounts
that do not require a password.