Managing Passwords

The password is the most important individual user identification symbol. With it, the system authenticates a user to allow access to the system. Because they are vulnerable to compromise when used, stored, or known, passwords must be kept secret at all times. The following sections discuss passwords in more detail.

System Administrator Responsibilities

The system administrator and every user on the system must share responsibility for password security. System administrators perform the following security tasks:

Ensure that all users have passwords.
Maintain proper permissions on all system files, including the standard password and group files, /etc/passwd and /etc/group.
Delete or nullify user IDs and passwords of users no longer eligible to access the system.
Verify that all application passwords are encrypted.
Verify that permissions on /var/adm/btmp and /var/adm/wtmp are set appropriately.
Implement one-time passwords for single guest access.
Inform users of their responsibilities regarding password security.
Use password aging to force users to change their passwords regularly.
Prevent reuse of recent passwords.
Configure systemwide security attributes in the /etc/default/security file. See Section and refer to security(4) for more information.
Convert the system to use shadow passwords. See Section and refer to shadow(4) and pwconv(1M) for more information.

User Responsibilities

Every user must observe the following rules:

Remember the password and keep it secret at all times.
Change the initial password immediately and continue to change it.
Report any changes in status and any suspected security violations.
Make sure no one is watching a password being entered.

Criteria of a Good Password

Observe the following guidelines when choosing a password and communicate these guidelines to users:

Choose a password with at least 6 characters and no more than 80 characters. Special characters can include control characters and symbols, such as asterisks and slashes. In standard mode, only the first 8 characters are used.
Do not choose a word found in a dictionary in any language, even if you spell it backwards. Software programs exist that can find and match it.
Do not choose a password easily associated with you, such as a family or pet name, or a hobby.
Do not use simple keyboard sequences, such as asdfghjkl, or repetitions of your login (for example, if your login is ann; a bad password choice is annann).
Consider using misspelled words or combined syllables from two unrelated words to make suitable passwords. Another popular method is to use the first characters of a favorite title or phrase for a password.
Consider using a password generator that combines syllables to make pronounceable gibberish.
Do not share passwords with other users. Management must forbid sharing of passwords.
Always have a password. Do not have your password field cleared in the /etc/passwd file.

Changing the /etc/passwd Password File

A standard system maintains one password file: /etc/passwd.

All passwords are encrypted immediately after entry, and stored in the password file, /etc/passwd. Only the encrypted password is used in comparisons.

Follow these guidelines if you need to change the password file:

Do not permit any empty or null password fields; this is a security breach. An empty password field enables any user to set the password for that account.
Do not edit the password file directly. Use HP SMH or the useradd, userdel, or usermod commands to modify password file entries. If you must edit the password file directly, use the vipw command and check it with the pwck command. See vipw(1M) and pwck(1M) for more information.

Examples of passwd Commands

Following are some useful passwd command examples:

Reset a user's password:
# passwd user1
Force a password change at next login:
# passwd -f user1
Lock or disable an account:
# passwd -l user2
Enable password aging:
# passwd -n 7 -x 28 user1
View password aging status for a specific user:
# passwd -s user
View password aging status for all users:
# passwd -sa

The /etc/passwd File Format

The /etc/passwd file is used to authenticate a user at login time. The file contains an entry for every account on the HP-UX system. Each entry consists of seven fields, separated by colons. A typical /etc/passwd entry looks like this:

robin:Z.yxGaSvxAXGg:102:99:Robin Hood,Rm 3,x9876,408-555-1234:/home/robin:/usr/bin/sh

The fields contain the following information (listed in order), separated by colons:

robin—User (login) name, consisting of up to 8 characters.
Z.yxGaSvxAXGg—Encrypted password field.
102—User ID, an integer ranging from 0 to MAXINT-1 (equal to 2,147,483,646 or 2³¹ -2).
99—Group ID, from /etc/group, an integer ranging from 0 to MAXINT-1.
Robin Hood,Rm 3,x9876,408-555-1234—Comment field, used to identify such information as the user's full name, location, and phone numbers. For historic reasons, this is also called the gecos field.
/home/robin—Home directory, the user's initial login directory.
/usr/bin/sh—Login shell path name, executed when the user logs in.

The user can change the password by invoking passwd, the comment field (fifth field) with chfn, and the login program path name (seventh field) with chsh. The system administrator sets the remaining fields. The user ID must be unique. See chfn(1), chsh(1), passwd(1), and passwd(4) for more information.

The /etc/shadow Shadow Password File

Increasing computational power available to malicious password decrytpers has made the nonhidden passwords in the /etc/passwd file vulnerable to decryption.

A shadow password enhances system security by hiding encrypted passwords in a shadow password file. You can move encrypted passwords previously stored in the publicly readable /etc/passwd file to the /etc/shadow file, which is accessible only by a user with the appropriate privileges.

Use the following commands to enable, verify, and disable shadow passwords:

The pwconv command creates a shadow password file and copies the encrypted passwords from the /etc/passwd file to the /etc/shadow file.
The pwck command checks the /etc/passwd and /etc/shadow files for inconsistencies.
The pwunconv command copies the encryped passwords and aging information from the /etc/shadow file to the /etc/passwd file and then deletes the /etc/shadow file.

For more information, see pwconv(1M), pwck(1M), pwunconv(1M) and shadow(4).

Note the following points about the shadow password feature.

When the shadow password feature is enabled, applications can be affected if they directly access the password field of the /etc/passwd file to obtain password and aging information. That field will now contain an x, indicating that the information is in /etc/shadow.
Applications that use the PAM interfaces to authenticate, are not effected.
To access the /etc/shadow file programmatically, use the getspent() calls. These calls are similar to the getpwent() calls for /etc/passwd. For more information, see getspent(3C) and getpwent(3C).
In the /etc/nsswitch.conf file, shadow passwords are supported with files, NIS, and LDAP name services, but they may not be supported with other name server switch backends. To configure the system to use only files, NIS, and/or LDAP, ensure that the passwd line in /etc/nsswitch.conf contains only files, NIS, and/or LDAP. If /etc/nsswitch.conf does not exist, or if the passwd line is not present, then the default is files only. For more information, see nsswitch.conf(4).
The shadow password is based on the de facto standard provided with other UNIX systems.

The following attributes, defined in /etc/default/security, apply to shadow passwords. See Section and consult the security(4) manpage for more information.

INACTIVITY_MAXDAYS—Number of days before expiring an account for inactivity.
PASSWORD_MINDAYS—Minimum number of days before a password can be changed.
PASSWORD_MAXDAYS—Maximum number of days that passwords are valid.
PASSWORD_WARNDAYS—Number of days before warning users of password expiration.

Shadow passwords are supported with these products:

Lightweight Directory Access Protocol (LDAP)
Ignite-UX Directory Access Control (LDAP)
Serviceguard

Shadow passwords are not supported by the applications that expect passwords to reside in /etc/passwd.

For more information, see the following manpages:

passwd(1), pwck(1M), pwconv(1M), pwunconv(1M), getspent(3C), putspent(3C), nsswitch.conf(4), passwd(4), security(4), shadow(4)

Eliminating Pseudo-Accounts and Protecting Key Subsystems in /etc/passwd

By tradition, the /etc/passwd file contains numerous “pseudo-accounts,” which are entries not associated with individual users and which do not have true interactive login shells.

Some of these entries, such as date, who, sync, and tty, evolved strictly for user convenience, providing commands that could be executed without logging in. To tighten security, they have been eliminated in the distributed /etc/passwd so that these programs can be run only by a user who is logged in.

Other such entries remain in /etc/passwd because they are owners of files. Programs with owners such as adm, bin, daemon, hpdb, lp, and uucp encompass entire subsystems, and represent a special case. Because they grant access to files they protect or use, these programs must be allowed to function as pseudo-accounts, with entries listed in /etc/passwd. The customary pseudo- and special accounts are shown in Example 2-1.

Example 2-1 Pseudo- and Special System Accounts

root::0:3::/:/sbin/sh
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
uucp:*:5:3::/var/spool/uucppublic:/usr/lbin/uucp/uucico
lp:*:9:7::/var/spool/lp:/sbin/sh
nuucp:*:11:11::/var/spool/uucppublic:/usr/lbin/uucp/uucico
hpdb:*:27:1:ALLBASE:/:/sbin/sh
nobody:*:-2:-2::/:

The key to the privileged status of these subsystems is their ability to grant access to programs under their jurisdiction without granting root access (uid 0). Instead, the setuid bit for the executable file is set and the effective user of the process corresponds to the owner of the executable file. For example, the cancel command is part of the lp subsystem and runs as effective user lp.

When the setuid is set, the security mediation of that subsystem enforces the security of all programs encompassed by the subsystem, not the entire system. Hence, the subsystem vulnerability to a breach of security is also limited to only those subsystem files. Breaches cannot affect the programs under different subsystems. For example, programs under lp do not affect those under daemon.

Secure Login with HP-UX Secure Shell

The HP-UX Secure Shell provides secure remote login, file transfer, and remote command execution. All client-server communication is encrypted. Passwords going across the network are never sent in clear text. For more information, see ssh(1) and Section .

Securing Passwords Stored in NIS

The Network Information Service (NIS) is part of the Network File System (NFS). NIS enables configuration administration of several hosts from a central location, a master server. Instead of having host configurations stored separately on each host, the information is consolidated onto a central location. The /etc/password file is among the several configuration files stored on the NIS server.

The /etc/shadow shadow password file is not supported on NIS.

See the NFS Services Administrator's Guide for information about NIS.

Securing Passwords Stored in LDAP Directory Server

LDAP-UX Client Services interoperates with PAM to authenticate passwords stored on an LDAP directory server. The PAM_LDAP library provides the authentication service.