Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP Servers and Workstations: Managing Systems and Workgroups > Chapter 8 Administering a System: Managing System Security

Managing Trusted Passwords and System Access

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

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 first part of this section is similar to the section “Managing Standard Passwords and System Access”, but with a Trusted System point of view. The standard section also contains the following information on protecting system access.

Security Administrator’s Responsibilities

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 (temporary passwords) for 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 new password.

  • Maintains proper permissions on all system files, including the standard password file /etc/passwd and the trusted database files /tcb/files/auth/*.

  • Establishes password aging.

  • Manages password reuse.

  • Deletes and/or nullifies expired passwords, user IDs and passwords of users no longer eligible to access the system.

User’s Responsibility

Every user must observe the following rules:

  • Remember the password and keep it secret at all times.

  • Change the initial password immediately; change the 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 and can have up to 80. Special characters can include control characters and symbols such as asterisks and slashes. In standard mode, only the first eight characters are used. In trusted mode, all 80 are significant.

    After a conversion to a Trusted System, only the first eight characters of a converted password will be acceptable. Users who had a longer password on the standard system must log in for the first time on the Trusted System with only the first eight characters. Then they may choose a longer password, if they desire. If a system is converted back to standard mode, the passwords are truncated to the first eight characters.

  • 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 (e.g., if your login is ann; a bad 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.

Password Files

A Trusted System maintains multiple password files: the /etc/passwd file and the files in the protected password database /tcb/files/auth/ (see “The /tcb/files/auth/ Database”). Each user has an entry in two files, and login looks at both entries to authenticate login requests.

If NIS+ is configured, this process is more complex; see “Network Information Service Plus (NIS+)”.

All passwords are encrypted immediately after entry, and stored in /tcb/files/auth/user-char/user-name, the user’s protected password database file. Only the encrypted password is used in comparisons.

Do not permit any empty/null 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, userdel, 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 being unable to login. In this case, remove the mapping files. The system will automatically regenerate new mapping files.

The /etc/passwd File

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

robin:*: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:

  1. User (login) name, consisting of up to 8 characters. (In the example, robin)

  2. Unused password field, held by an asterisk instead of an actual password. (*)

  3. User ID (uid), an integer ranging from 0 to MAXINT-1, equal to 2,147,483,646 or 231 -2. (102)

  4. Group ID (gid), from /etc/group, an integer ranging from 0 to MAXINT-1. (99)

  5. Comment field, used for identifying information such as the user’s full name, location, and phone numbers. For historic reasons, this is also called the gecos field. (Robin Hood,Rm 3,x9876,408-555-1234)

  6. Home directory, the user’s initial login directory. (/home/robin)

  7. Login program path name, executed when the user logs in. (/usr/bin/sh)

The user can change 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 should be unique. See chfn(1), chsh(1), passwd(1), and passwd(4). The user can change the password in the protected password database with passwd.

The /tcb/files/auth/ Database

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, the authentication profile for user david is stored in the 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. See prpwd(4) for more information on these entries, which include:

  • User name and user ID.

  • Encrypted password.

  • Account owner.

  • Boot flag: whether the user can boot to single user mode or not. (See security(4).)

  • Audit ID and audit flag (whether audit is on or not).

  • Minimum time between password change.

  • Password maximum length.

  • 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 the account is locked.

  • Number of days before expiration when a warning will appear.

  • Whether passwords are user-generated or system-generated.

  • Whether a triviality check is performed on a user-generated password.

  • Type of system-generated passwords.

  • Whether null passwords are allowed for this account.

  • User ID of last person to change 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 for the use of login and group names, login and group name permutations, and palindromes.

    A new password must differ from the old password by at least three characters.

  • System-generated passwords using a combination of letters only.

  • System-generated passwords using a combination of letters, numbers, and punctuation characters.

  • System-generated passwords using pronounceable meaningless syllables.

Password generation options may be set for a system. Also, the system administrator can set password generation options on a per-user basis, overriding 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:

  • Minimum time. 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.

  • Expiration time. A time after which a user must change that password at login.

  • Warning time. The time before expiration when a warning will be issued.

  • Lifetime. 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.

Password History and Password Reuse

On Trusted Systems, the system administrator can enable the password history feature on a system-wide basis to discourage users from reusing from one to ten previous passwords.

You enable password history by defining the following parameter as a line in the file /etc/default/security:

PASSWORD_HISTORY_DEPTH=n

where n is an integer from 1 to 10, specifying the number of previous passwords to check. If n is less than 1, or the entry is missing, it defaults to 1; if n is greater than 10, it defaults to 10.

When a user changes his/her password, the new password is checked against the previous n passwords, starting with the current password. If any match, the new password is rejected. An n of 2 prevents users from alternating between two passwords.

See passwd(1) and security(4) for further details.

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. A superuser can log in outside the allowed access time, but the event is logged. The permitted range of access times is stored in the protected password database for users and may be set with SAM. Users that are logged in when a range ends are not logged out.

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/devassign, which contains an entry for each terminal 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:

  • Device name.

  • 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.

  • Terminal lock flag.

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 library routines in the following manpages can be used to access information in the password files and other Trusted System databases.

getdvagent(3)

Manipulate device entries in /tcb/files/devassign.

getprdfent(3)

Manipulate system defaults in /tcb/files/auth/system/default.

getprpwent(3)

Get password entries from /tcb/files/auth/.

getprtcent(3)

Manipulate terminal control database, /tcb/files/ttys.

getpwent(3C)

Get password entries from /etc/passwd.

putpwent(3C)

Write password file entries to /etc/passwd.

getspwent(3X)

Get password entries from /tcb/files/auth/, provided for backward compatibility.

putspwent(3X)

Write password entries to /tcb/files/auth/, provided for backward compatibility.

putprpwnam(3)

Write password file entries to /tcb/files/auth/.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 1997-2006 Hewlett-Packard Development Company, L.P.