 |
» |
|
|
|
The password is the most important individual user identification
symbol. With it, the system authenticates a user to allow access
to the system. Since they are vulnerable to compromise when used,
stored, or known, passwords must be kept secret at all times. The security administrator and every user on the system must
share responsibility for password security. The security administrator
performs the following security tasks: Generates Authorization Numbers for
the system and to new users. To maintain password privacy, SAM generates
an Authorization Number for each new account. This number must be
used for first login. Once this number has been verified, the new
user is prompted for a password. This process shields user passwords
even from the system administrator. Maintains proper permissions on the /etc/passwd
and the protected password, /tcb/files/auth/user_initial/user_name
files. Establishes password aging. Deletes/nullifies expired passwords, user IDs and
passwords of users no longer eligible to access the system.
Every user must observe the following rules: Remember the password and keep it
secret at all times. Change initial password immediately; change password
periodically. Report any changes in status and any suspected security
violations. Make sure no one is watching when entering the password. Choose a different password for each machine on
which there is an account.
Criteria of a Good Password | |
Observe the following guidelines when choosing a password: A password must have at least six
characters. Special characters can include control characters and
symbols such as asterisks and slashes. Do not choose a word found in a dictionary, 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 (e.g. login is ann;
password is annann). Misspelled words or combined syllables from two
unrelated words 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.
Management must forbid sharing of passwords. It is a security
violation for users to share passwords. Two Password Files | |
A trusted system maintains two password files: the /etc/passwd
file and the protected password database, /tcb/files/auth/user_initial/user_name.
Every user has entries in both files, and login
looks at both entries to authenticate login requests.
All passwords are encrypted immediately after entry, and stored
in the password file: /etc/passwd
for standard HP-UX, and /tcb/files/auth/user_initial/user_name
for trusted systems. Only the encrypted password is used in comparisons. Do not permit any empty password fields in either password
file. On trusted systems, the password field in /etc/passwd
is ignored. A user with an empty password will be forced to set
a password upon login on a trusted system. However, even this leaves
a potential for security breach, because any
user can set the password for that account before a password is
set for the first time. Do not edit the password files directly. Use SAM, useradd,
or usermod to
modify password file entries. HP-UX generates these mapping files
to provide faster access to the password files.
/tcb/files/auth/system/pw_id_map |
/tcb/files/auth/system/gr_id_map |
/tcb/files/auth/system/aid_id_map |
It is possible for these mapping files to get out of sync
with the password database files, resulting in users unable to login.
In this case, remove the mapping files. The system will automatically
regenerate new mapping files. The /etc/passwd
file is used to authenticate a user at login time for standard HP-UX.
The file contains descriptions of every account on the HP-UX system.
Each entry consists of seven fields, separated by colons. A typical
entry of /etc/passwd
in a trusted system looks like this: robin:*:102:99:RobinTewes:/mnt/robin:/bin/csh |
The fields contain the following information (listed in order): User (login) name, consisting of up to 8 characters. Encrypted password field, held by an asterisk instead
of an actual password. User ID (uid),
an integer less than 60000. Group ID (gid),
from /etc/group,
an integer less than 60000. Comment field, used for identifying information
such as the user's full name. Home directory, the user's initial login directory. Login program 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 uid
must be unique. See passwd(1) and passwd(4). When a system is converted to a trusted system, the encrypted
password, normally held in the second field of /etc/passwd,
is moved to the protected password database, and an asterisk holds
its place in the /etc/passwd
file. Protected password database files are stored in the /tcb/files/auth
hierarchy. User authentication profiles are stored in these directories
based on the first letter of the user account name. For example,
authentication profile for user david
is stored in file /tcb/files/auth/d/david. On trusted systems, key security elements are held in the
protected password database, accessible only to superusers. Password
data entries should be set via SAM. Password data which are not
set for a user will default to the system defaults stored in the
file /tcb/files/auth/system/default. The protected password database contains many authentication
entries for the user. prpwd(4) provides more
information on these entries. These entries include:
Boot flag - whether the user can boot to single
user mode or not. Audit ID and audit flag (whether audit is on or
not). Minimum time between password change. Password expiration time, after which the password
must be changed. Password lifetime, after which the account is locked. Time of last successful and unsuccessful password
change. Absolute time (date) when the account will expire. Maximum time allowed between logins before account
is locked. Number of days before expiration when warning will
appear. Whether passwords are user-generated or system-generated. Whether triviality check is performed on user-generated
password. Type of system-generated passwords. Whether null passwords are allowed for this account. User ID of the last person to change the password,
if not the account owner. Time periods when this account can be used for login. The terminal or remote hosts associated with the
last successful and unsuccessful logins to this account. Number of unsuccessful login attempts; cleared upon
successful login. Maximum number of login attempts allowed before
account is locked.
Password Selection and Generation | |
On trusted systems, the system administrator can control how
passwords are generated. The following password generation options
are available: User-generated passwords. A password screening option is available to check a user-generated
password against the dictionary and check for the use of login names,
login name permutations, repeated characters, and palindromes. System-generated passwords using a combination of
letters only. System-generated passwords using a combination of
letters, numbers, and punctuation characters. System-generated pronounceable password phrases,
based on English.
Password generation options may be set for a system. Also,
the system administrator can set password generation options per
user basis, which override the system default. At least one password generation option must be set for each
user. If more than one option is available to a user, a password
generation menu is displayed when the user changes his password. Password Aging | |
The system administrator may enable or disable password aging
for each user. When password aging is enabled, the system maintains
the following for the password: The minimum time
of a password specifies the minimum time required between password
changes. This prevents users from changing the password and then
changing it back immediately to avoid memorizing a new one. The expiration time of a
password specifies a time after which a user must change that password
at login. The warning time specifies
the time before expiration when a warning will be issued. The lifetime of a password
specifies the time at which the account associated with the password
is locked if the password is not changed. Once an account is locked,
only the system administrator can unlock it. Once unlocked, the
password must still be changed before the user can log into the
account.
The expiration time and lifetime values are reset when a password
is changed. A lifetime of zero specifies no password aging; in this
case, the other password aging times have no effect. Time-Based Access Control | |
On trusted systems, the system administrator may specify times-of-day
and days-of-week that are allowed for login for each user. When
a user attempts to log in outside the allowed access time, the event
is logged (if auditing is enabled for login failures and successes)
and the login is terminated. The superuser can log in outside the
allowed access time, but the event is logged. The access time is
stored in the protected password database for users and may be set
via SAM. Device-Based Access Control | |
For each mux port and dedicated DTC port on a trusted system,
the system administrator can specify a list of users allowed for
access. When the list is null for a device, all users are allowed
access. The device access information is stored in the device assignment
database, /tcb/files/auth/devassign,
which contains an entry for each device on the trusted system. A
field in the entry lists the users allowed on the device. Terminal login information on a trusted system is stored in
the terminal control database, /tcb/files/ttys,
which provides the following data for each terminal: user ID of the last user to successfully log into
the terminal last successful login time to the terminal last unsuccessful login time to the terminal number of consecutive unsuccessful logins before
terminal is locked
Only superusers may access these trusted system databases
and may set the entries via SAM. See devassign(4)
and ttys(4) for more information. Manipulating the Trusted System Databases | |
The following library routines can be used to access information
in the password files and other trusted system databases. Refer
to Section 3 of the HP-UX Reference for details. Title not available (Manipulating the Trusted System Databases ) - getpwent
Get password entries from /etc/passwd - getprpwent
Get password entries from /tcb/files/auth/*/* - getspwent
Get password entries from /tcb/files/auth/*/*,
provided for backward compatibility - putpwent
Write password file entries to /etc/passwd - putprpwnam
Write password file entries to /tcb/files/auth/*/* - putspwent
Write password file entries to old secure password
file format, provided for non-HP software compatibility. Will not
work with protected password database. - getdvagent
Manipulates device entries in /tcb/files/auth/devassign - getprdfent
Manipulates system defaults in /tcb/files/auth/system/default - getprtcent
Manipulates terminal control database, /tcb/files/ttys
Eliminating Pseudo-Accounts and Protecting Key Subsystems | |
By tradition, the /etc/passwd
file contains numerous "pseudo-accounts" — 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, have
evolved strictly for user convenience. To tighten security, they
have been eliminated in /etc/passwd
so that these programs can be performed only by a user who is logged
in. Other such entries remain in /etc/passwd
because each are owners of files. Among them are bin,
daemon, adm,
uucp, lp,
and hpdb. Programs with owners such as bin,
uucp, adm,
lp, and daemon
encompass entire subsystems, and represent a special case. Since
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. adm:*:4:4::/usr/adm:/bin/sh |
uucp:*:5:3/usr/spool/uucppublic:/usr/lib/uucp/uucico |
lp:*:9:7/usr/spool/lp:/bin/sh |
nso:*:20:4:Network Security Officer:/users/nso:/usr/bin/ksh |
Key to the privileged status of these subsystems is their
ability to grant access to programs under their jurisdiction, without
granting a user ID of 0. Instead, the setuid
bit is set and the uid
bit is set equal to the specified subsystem (for example, uid
is set to lp). Once set, security mediation of that subsystem enforces the
security of all programs encompassed by the subsystem, not the entire
system. However, the subsystem's vulnerability to breach of security
is also limited to the subsystem files only. Breaches cannot affect
the programs under different subsystems (for example, programs under
lp do not affect
those under daemon). System Access by Modem | |
To protect against system penetration via modem, observe these
precautions: Require use of a hardware dial-back
system for all interactive modems. Require an additional password from modem users,
by adding an entry for the modem device in /etc/dialups
and, optionally, /etc/d_passwd.
Have users renew their dial-in accounts frequently. Cancel modem access promptly when a user is no longer
an employee. Establish a regular audit schedule to review remote
usage. Connect the modems and dial-back equipment to a
single HP-UX CPU, and allow network services to reach the destination
CPU from that point. Exceptions to dial-back must be made for UUCP access.
Additional restrictions are possible through proper UUCP configuration.
Another potential exception is file transfer via kermit. If a security breach with unknown factors occurs,
shut down both network and telephone access and inform the network
administrator. To maximize security when configuring a dial-back
modem system, dedicate the dial-out mechanism to the dial-out function
only. It should not be configured to accept dial-in. Use another
modem on another telephone line for your dial-in service.
|
Printable version
