In order to ensure that the users on your system are the same people who have been entrusted to use it properly, Identification and Authentication improvements have been implemented. Some of these improvements are described in this chapter. The Kerberos authentication system has also been included in this distribution, and represents a significant improvement over conventional identification and authentication tools. Kerberos is described in Chapter 7, “Administering CSP-Kerberos.”
In the unlikely event that an individual user breaks a security policy, that user must be held strictly accountable for his or her actions. Holding the owner of a user account responsible for the actions taken with that account is reasonable only if steps have been taken to assure that the individual using that account is in fact the individual assigned to the account. Trusted systems usually implement certain facilities to assure that users are adequately identified and that they authenticate themselves to the system with a password. To log in, the user must know
a valid login name for the system
the password associated with that login name
Because these items are all that is needed to gain access to your system, these pieces of information are created, closely guarded and maintained according to strict procedures outlined in this chapter. Of the two items of information, the most crucial is the account password. The login names are known to many people, or can easily be determined. It is possible to log in without specifying a label if the default label has been set, but the password is absolutely necessary. If a password is compromised or stolen, all information that is available to the user associated with the password is also compromised.
Passwords are the only mechanism available to authenticate your users. Once IRIX has accepted a user's password as valid, that user has access to all files available at his or her clearance for the duration of the login session.
The dangers involved when passwords are compromised cannot be overstated. An intruder can access all files available to the user at any time. Other features of IRIX make it likely that an intruder would be swiftly identified and locked out, but a tremendous amount of damage can take place in a short time if the accountability and Identification and Authentication procedures are not followed.
Many features taken for granted in standard IRIX are restricted in the Commercial Security Pak. In the area of user passwords, there are facilities to force the user to choose a system-generated password (which is random and difficult to guess) and the length of time that this password is valid can be specified (with both a minimum and maximum lifetime). The encrypted password is not visible to users. When the encrypted password is visible, a potential intruder may copy it and attempt to break the encryption.
If you choose to allow users to select their own passwords, a strict set of checks are performed on the passwords to disallow passwords without enough variation in the characters used. For example, all passwords must use a combination of letters, numerals, and control characters.
Password aging is defined as being able to set a minimum and maximum lifetime for passwords. IRIX supports this feature, and it is described in detail in the guide titled IRIX Admin: System Configuration and Operation .
Password aging is a very useful feature. By limiting the amount of time a password may be in use, you limit the amount of time a potential interloper has to crack the password. By enforcing a minimum password lifetime, you prevent lazy users from simply changing their password briefly and then returning to their usual password immediately.
If a user does not change their password within the specified time period, the user is forced to change the account password when they next try to log in. Any user can place the following line in .login or .profile to notify them when password expiration is imminent:
showpwage username |
By default, showpwage(1) notifies the user only if the password is within seven days of expiration. This default can be changed with the -d flag. See the showpwage(1) reference page for a complete description of this command.
Generally, the only time that an account becomes locked is when the user is away for an extended period. But once locked, an account can be unlocked only by the Superuser or System Administrator. When the account is locked, the encrypted password is replaced by this string:
*LK* |
To unlock the account, the System Administrator uses the dbedit(1) utility to remove the string from the password field for that account. Then, the Superuser should force the user to choose a new password by executing this command:
passwd -f username |
Password aging is enforced for a particular user if his or her encrypted password in the /etc/shadow file is followed by a comma and a non-null string of characters from the 64-character alphabet:
. / 0-9 A-Z a-z |
The first character of the entry, Maximum, denotes the maximum number of weeks for which a password is valid. A user who attempts to log in after his or her password has expired is forced to change the password. The next character, minimum, denotes the minimum period in weeks that must pass before the password may be changed. If the second character is omitted, zero weeks is the default minimum. M and m have numerical values in the range 0-63, which correspond to the 64-character alphabet shown above (for example, / = 1 week; z = 63 weeks). If minimum = Maximum = 0 (derived from the string . or ..), the user is forced to change the password at the time of the next login (and the “age” disappears from the entry in the shadow file). If minimum > Maximum (signified, for example, by the string ./), only the Superuser can change the password. This is often done for accounts that are used for uucp logins. For example, the command
passwd -x1 -n10 nuucp |
disallows the user from changing the password. For complete information on how to put an age limit on a user's password, consult the passwd(1) reference page.
There are several options available to the security officer when deciding on password generation policy. IRIX comes equipped with a default password generation utility, /sbin/passwd_gen, but also allows the individual site to install a custom password generating program. If you have a custom password generator you wish to use, you may replace /sbin/passwd_gen with your own program, subject to the following constraints:
The Site Security Officer is willing to accept the risk of using an unevaluated configuration.
The new program must be placed in the /sbin directory and renamed passwd_gen.
The owner of the file must be root.
The group of the file must be sys.
The DAC permission of the file must be 555 (-r-xr-xr-x).
Your system is no longer running the evaluated software configuration.
Additionally, any custom password generation program must generate a set of passwords on one line, separated by blank spaces.
To allow password selection, simply log in as the Superuser and rename the /sbin/passwd_gen file to a different name.
The default generator presents the user with five selected passwords, and the user is free to accept or reject any of these. If the user does not accept any of the offered passwords, he or she may press the Enter key to obtain a new set of passwords.
If you do not wish to implement password generation at your site, you may remove or rename the passwd_gen program. Once this is done, users are free to select their own passwords, subject to the following triviality checks:
Each password must have at least six characters. However, only the first eight characters are significant.
The password must contain at least two alphabet characters and one numeric character.
The password must not be related to the user's login name. Any reversing or circular shift of the characters in the login name are not allowed. For the purposes of this test, capital letters are assumed to be equivalent to their lowercase counterparts.
The password must have at least three characters different from the previous password. For the purposes of this test, capital letters are assumed to be equivalent to their lower case counterparts.
Note that if password generation is in effect, the generated passwords are not subject to these triviality checks since more stringent checks are applied internally.
The IRIX password generator produces passwords of seven lowercase alphabet characters in length. The IRIX password generator attempts to produce pronounceable passwords, so it produces far fewer than the maximum possible number of passwords. The total password space (the total number of passwords that the generator can possibly produce) is 35,431,196 different passwords. This number is computed based on the size and number of phonemes available for combination into words and the method by which they're combined.
IRIX limits the total password guessing rate (for all accounts, on all tty and pty ports) to no more than one password per second. This guess rate is not user-configurable. Thus, a person who knew what parameters were used by the password generation program, who had unrestricted access to a IRIX system, and who was capable of attempting to log in once per second would be able to guess any password generated by that algorithm in, at most, 35,431,196 seconds, which is 410 days of uninterrupted guessing. In 41 days of uninterrupted guessing, the person would have a 10% chance of guessing any password. In 35 seconds, the person would have a “one in a million” chance of guessing a correct password for a given account.
Of course, it is extremely unlikely that someone attempting to break into an IRIX system would know the parameters used to generate passwords, or have unrestricted access to a well-maintained trusted system, so the rate of guessing would necessarily be much lower. If password aging is implemented, requiring users to change their passwords monthly, the chance of a potential intruder correctly guessing a password is negligible.
The password generator relies on a “pseudo-random” number generator, which is described in the random(3) reference page.
The password step can be eliminated from the login process if the user has no password set and the string
passwdreq=0 |
appears in the login.options file. This means that a user who does not have an initial password set does not have to create one or enter any password to log in. Obviously, this is a highly insecure practice, and you should not allow it on your system.
It is recommended that you have passwdreq set to 2 on your system at all times. The effect of setting passwdreq to 2 is described below. However, even if passwords are not required on a particular system, any user who maintains a password on his or her account must enter it at login time. Regardless of whether passwords are required, the system does not allow access to a passworded account without receiving the correct password.
If the string
passwdreq=1 |
appears in the login.options file, passwords are always required on the system and a user without a password is prompted to choose one immediately. This is the default behavior for the Commercial Security Pak.
If the passwdreq line reads
passwdreq = 2 |
then a user without a password already set is not allowed access and sso must create a password for the user before he or she can log in.
Assuming that the user enters the correct password, no other user input is required to complete the login process. If the password or any previous entry was incorrectly entered, the system responds with
Login incorrect. Try again. |
and the login process is aborted.
If the account is new and has no password and passwords are required, the user sees this prompt:
Enter New Password: |
At this time, the user is forced to enter a password before being allowed to complete the login process. The user is always prompted to re-enter the new password as an error check.
During the login process, login failures are counted and compared against the values set in the login.options file. The line
maxtries = number |
indicates the number of unsuccessful attempts allowed per login port. The default value for this keyword is 5. If the user unsuccessfully attempts to log in 5 consecutive times on the same terminal, the system disallows logins on that terminal for the number of seconds specified in the login.options file by this entry:
disabletime = number |
The default value for disabletime is 20 seconds. The sso account is exempt from this restriction, since it may be necessary for sso to log in quickly in an emergency.
If the keyword syslog is in the login.options file with either of the following settings, unsuccessful login attempts are placed in the system log with the date and time:
syslog = all syslog = fail |
The login.options file allows you to set the options for all users on the system as shown in Table 6-1.
Option | Default Value | Meaning |
|---|---|---|
maxtries | 5 | Maximum consecutive number of unsuccessful login attempts to any login name through the same port. A 0 in this space indicates “no limit.” |
disabletime | 20 | The amount of time in seconds login waits before ending the session after maxtries unsuccessful attempts. |
passwdreq | 0 | This field indicates whether passwords are required. If this field contains a 0, passwords are not required. If the field contains a 1, you may select a password when you log in if you do not have one. If the field contains a 2, you may not log in without a previously set password. |
lastlog | 1 | This field indicates whether the user is to be notified about the last successful login attempt. A 1 in this field indicates that the user should be notified. If a 0 is present in this field, notification is suppressed. |
syslog | all | This field directs the system to log all successful and failed login attempts to the system log. If the value in the field is fail, then only failed attempts are logged. |
After your installation is complete, you may edit the login.options file to enforce your particular system security policies. Before you edit the file, be sure to make a backup copy of the original. If the file is removed, the default values in effect at installation time are used.
When the user logs in, the system encrypts the password and tests it against the encrypted password for the account listed in the /etc/shadow file. The /etc/passwd file is still in existence, though, and still contains all pertinent user information except the encrypted password. The passwd file also contains information about the minimum and maximum age of that user's password.