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
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
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.
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
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:
Force a password change at next login:
Lock or disable an account:
Enable password aging:
# passwd -n 7 -x 28 user1
View password aging status for a specific user:
View password aging status for all users:
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.
ID, an integer ranging from 0 to MAXINT-1 (equal to 2,147,483,646 or 231 -2).
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
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
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.
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.
of days before expiring an account for inactivity.
number of days before a password can be changed.
number of days that passwords are valid.
of days before warning users of password expiration.
Shadow passwords are supported with these products:
Lightweight Directory Access
Ignite-UX Directory Access
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
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
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.