7.3 User Authentication Revisited | Essential System Administration, Third Edition

We've already looked at the issues surrounding password selection and aging in Section 6.4. In this section, we will consider optional user authentication methods and techniques that extend beyond standard password selection and aging. We will also consider another method of securing remote access the secure shell later in this chapter.

7.3.1 Smart Cards

The purpose of all user authentication schemes, from passwords on, is to require a prospective user to prove that she really is the person she is claiming to be. The standard Unix login procedure and most secondary authentication programs validate a user's identity based on something she knows, like a password, assuming that no one else knows it.

There are other approaches to user authentication. A user can also be validated based on something she is, that is, some unique and invariant physical characteristic such a fingerprint^[2] or retina image. Biometric devices validate a person's identity in this way. They are commonly used to protect entrances to secure installations or areas, but they are seldom used just to authenticate users on a computer system.

^[2] Fingerprints have been recently demonstrated to be quite easy to counterfeit, so they cannot be recommended.

A third approach is to validate the user based upon something she has. That something, known generically as a token, can be as simple as a photo ID badge. In the context of login authentication, smart cards are used most often. Smart cards are small, ranging in size from more or less credit card-size to about the same size as a small calculator. Some of them operate as a simple token that must be placed into a reader before computer access is granted.

Other smart cards look something like a calculator, with a keypad and a display in which a number appears. Users are required to enter a number from the display in addition to their normal password when they log in to a protected computer. This type of card generally requires the user to enter a personal identification number (PIN) before the card will operate (to provide some protection if the card is lost or stolen). Smart cards are also often designed to stop working if anyone tries take them apart or otherwise gain access to their protected memory.

Once the correct PIN is entered, smart cards can work in several different ways. In the most common mode of operation, the user is presented with a number when he tries to log in, known as a challenge. He types that number into his smart card and then types the number the card displays the response into the computer. The challenge and response values are generated cryptographically.

Under another scheme, the number to give the computer appears automatically after the proper PIN is entered. In this case, the card is synchronized with software running on the target computer; the most elaborate cards of this type can be synchronized with multiple hosts and can also operate in challenge/response mode to access still other computers.

For me, the most convenient type of card is made by RSA Security (http://www.rsasecurity.com). These cards automatically generate new numeric passwords every 60 seconds. The cards have an internal clock in addition to their cryptographic functionality, ensuring that they remain synchronized with the server software running on the target system. These cards are most often used as an additional authentication mechanism for dialup and other remote system access.

Smart cards provide an effective and relatively low-cost means of substantially increasing login authentication effectiveness. While they do not replace well-chosen user passwords, the combination of the two can go a long way toward securing a computer system against user account-based attacks.

7.3.2 One-Time Passwords

One-time passwords (OTPs) are another mechanism designed primarily for additional authentication for remote users. As the name implies, such passwords can be used only a single time, after which they become invalid. In addition, successive passwords are not easily predictable. For these reasons, they are a good choice when clear-text passwords are necessary for remote access.

The OPIE package short for "One-time Passwords in Everything" is an open source facility for OTPs. It was written by Randall Atkinson, Dan McDonald, and Craig Metz, and was derived from the earlier S/Key package. It is available from http://www.inner.net/pub/opie/.

Once OPIE is built and installed, you must replace the login, ftp, su, and/or passwd commands with the versions provided with the package. For example:

# cd /bin # mv login login.save # ln -s opielogin login

Next, you must set up user accounts that you want to have use the OTPs. First, at the system console, you add the user account to the OPIE system:

# opiepasswd -c chavez                 Must be run on the system console. Adding chavez: Using MD5 to compute responses Enter new secret pass phrase:          not echoed Again new secret pass phrase:          not echoed ID chavez OTP key is 123 ab4567 ASKS BARD DID LADY MARK EYES

As with any password, the secret pass phrase should be chosen with care.^[3] Make it as long as possible (an entire sentence is good). The opiepasswd command displays the user identifying key and the first password.

^[3] All OPIE keys and passwords in these examples are simulated.

OPIE stores its information in the file /etc/opiekeys. This file is thus extremely sensitive and should be protected against all non-root access.

The opiekey command is used to generate OTPs:

$ opiekey 123 ab4567  Using the MD5 algorithm to compute response. Enter secret pass phrase: not echoed  ASKS BARD DID LADY MARK EYES $ opiekey -n 3 123 ab4567  Using the MD5 algorithm to compute response. Enter secret pass phrase: not echoed  121: TELL BRAD HIDE HIS GREY HATS 122: SAYS BILL NOT HERO FROM MARS 123: ASKS BARD DID LADY MARK EYES

In the second example, three passwords are generated. They are used in inverse numerical order (highest numbered to lowest numbered). Such a list can be printed for use when traveling, provided that users are aware of the need to keep it secure.

The opiekey command must not be run over the network, because the secret pass phrase would be transmitted in the clear, defeating the entire OPIE security mechanism. It must be run on the local system.

This is how an OPIE login session looks:

login: chavez otp-md5 123 ab4567 ext Response: ASKS BARD DID LADY MARK EYES $

The OPIE package includes a PAM module for systems that use PAM. For example, it might be included in an rlogin authentication stack as follows:

auth     required       pam_securetty.so auth     required       pam_nologin.so auth     required       pam_opie.so auth     required       pam_unix.so

This form of the stack uses both OPIE and normal Unix passwords. Alternatively, you could designate the OPIE module as sufficient and remove the pam_unix module to replace standard passwords with OTPs.

Note that only users added to the OPIE system with opiepasswd will be prompted for OTPs. In general, it is usually best to incorporate all users within the OPIE system, perhaps limiting the package's use to the system that accepts dialup and other remote connections.

When PAM is not in use, you can exempt users from using OPIE with the /etc/opieaccess configuration file. Entries in this file take the form:

action     net-or-host/netmask

Here are some examples:

deny    192.168.20.24/255.255.255.0      Require passwords from this host. permit  192.168.10.0/255.255.255.0       Exempt this subnet.

If this file does not exist, all access uses OPIE. This is the recommended configuration.

7.3.3 Solaris and HP-UX Dialup Passwords

Dialuppasswords add another level of user authentication for systems allowingdialup access via modems. When dialup passwords are in use, users are required to provide a dialup password in addition to their username and password before being allowed access to a system over a dialup line. Dialup passwords may also be used as a way to restrict dialup access to certain users (by only giving the password to them).

Dialup passwords are supported by HP-UX and Solaris.

The dialup password facility uses two configuration files: /etc/d_passwd , the dialup password file (described later in this section), and /etc/dialups (the file is occasionally named dial-ups on a few older systems), which lists the terminal lines that are connected to dial-in modems, one per line:

/dev/tty10  /dev/tty11

Users who log in through one of these terminal lines must supply a dialup password, as specified in the file /etc/d_passwd, or they will not be allowed access to the system. If you decide to use dialup passwords, enter all the terminal lines connected to modems into this file; even a single unprotected dialup line is a significant security risk.

The file /etc/d_passwd contains a set of encrypted dialup passwords. The dialup password required depends on the user's login shell.

In the following line, the d_passwd file contains three colon-separated fields:

shell:encrypted-password:                 Final field is left empty

shell is the complete pathname of a shell that can be listed in the user's passwd entry. The second field is the encrypted password. The final field is always empty, but the second colon is required.

In general, the dialup password file does not provide any support for generating the encrypted password; you must generate it yourself.

On HP-UX systems, you can do this using the -F option to the passwd command. For example:

# passwd -F /etc/d_passwd /bin/sh

On Solaris systems, encrypted dialup passwords may be generated by changing your own password and then copying the string that appears in the password or shadow password file into /etc/d_passwd. Be sure to change your password back afterwards.

If you decide to use the same dialup password for all user shells, you should encrypt them using different salts. Their encrypted representation will look different in the file, so it will not be obvious that they are the same password. Changing your own password to the same value a second time will also use a different salt and generate a different encoded string.

Here is a sample dialup password file:

/bin/sh:10gw4c39EHIAM:  /bin/csh:p9k3tJ6RzSfKQ:  /bin/ksh:9pk36RksieQd3:  /bin/Rsh:*:

In this example, there are specific entries for the Bourne shell, Korn shell, and C shell. Dialup access from the restricted Bourne shell (/bin/Rsh) is disabled by the asterisk in the password field. Users who use other shells may log in from remote terminals without giving an additional dialup password. However, I recommend that you assign a dialup password to all shells in use at your site (if you need dialup passwords, you need them for everyone).^[4]

^[4] If you decide to use dialup password forPPP access, you will have to modify the chat scripts accordingly to take the additional prompt into account.

Dialup passwords should be changed periodically, even if you don't impose any password-aging restrictions on user passwords. They must be changed whenever anyone who knows the dialup password stops using the system (as part of the general account deactivation procedure), or if there is any hint that an unauthorized user has learned it.

7.3.4 AIX Secondary Authentication Programs

The software supporting smart card numeric passwords is one type of secondary authentication program. In general, this term refers to any program that requires additional information from the user before accepting that he is who he claims to be. For example, a program might require the user to answer several questions about their personal preferences ("Which of the following flowers do you prefer?") and compare the responses to those given when the user was initially added to the system (the question may be multiple choice, with the four or five wrong responses chosen randomly from a much larger list). The theory behind this sort of approach is that even if someone discovers or guesses your password, they won't be able to guess your favorite flower, bird, color, and so on, and you won't need to write the answers down to remember them, either, since the questions are multiple choice. It also relies on there being enough questions and choices per question to make blind guessing extremely unlikely to succeed. To be effective, accounts must be automatically disabled afte r quite a small number of unsuccessful authentications (two or three).

AIX provides for an administrator-defined alternative login authentication method, which may be used in addition to or instead of standard passwords. A program is designated an authentication program in the file /etc/security/login.cfg, via a stanza defining a name for the authentication method (uppercase by convention) and specifying the pathname of the authentication program:

LOCALAUTH:     program = /usr/local/admin/bin/local_auth_prog

This stanza defines an authentication method LOCALAUTH using the specified program. Note that the standard AIX password authentication method is named SYSTEM.

Once a method is defined, it may be invoked for a user by including it in the list for the auth1 user attribute. You can modify this attribute from SMIT, by using the chuser command, or by editing /etc/security/user directly. For example, the first command below replaces the standard password authentication with the LOCALAUTH method for user chavez:

# chuser auth1=LOCALAUTH chavez # chuser auth1=SYSTEM,LOCALAUTH chavez

The second command adds LOCALAUTH as an additional authentication method, run after the standard password check for user chavez. The program defined in the LOCALAUTH method will be passed the argument "chavez" when user chavez tries to log in. Of course, it would be wise to test an additional authentication method thoroughly on a single account before installing it on the system as a whole.

User accounts also have an attribute named auth2. This attribute works in the same way that auth1 does. However, the user does not have to pass the authentication procedure to be allowed onto the system; more technically, the return value from any program specified in the auth2 list is ignored. Thus, auth2 is a poor choice for a secondary authentication program, but it will allow a system administrator to specify a program that all users must run at login time.

Social Engineering

Social engineering is the colorful term used to describe crackers' attempts to get users to tell them their passwords and other information about the system, and no discussion of account security is complete without some consideration of it. Most descriptions of such attempts seem laughably obvious, but unfortunately, P. T. Barnum was right. Experience shows that it is essential to include seemingly obvious points such as these in user security education:

No member of the system administration staff, other computing center staff, field service team, and so on, will ever ask you to reveal your password or any other information about the system. (This is to protect against the computer equivalent of the bank examiner scam.)
No law enforcement or local security officer will ever ask for such information, either.
Don't reveal such information to someone you don't know if they call asking for help with the system (i.e., pretending to be a new user).
Report any suspicious questions that anyone asks you to the system administrator (or other designated person) right away.

Social-engineering techniques are generally an indication that someone has targeted your particular installation, which is why suspicious questions from outsiders need to be taken seriously.

You may also want to warn users against other unwise practices, such as sending local proprietary information or personal credit card numbers over the Internet (or generally including in email any information that they want to remain private), even though these practices do not impact system security as such.

7.3.5 Better Network Authentication: Kerberos

So far, we've seen several attempts at strengthening user authentication in various ways. TheKerberos system provides another mechanism for securing network authentication operations. Its goal is to allow systems and services to be secure within a network environment controlled by an adversary. Its strategy for accomplishing this is to make sure that no sensitive data is ever sent across the network.

This section provides a very brief introduction to Kerberos Version 5. Figure 7-1 illustrates the basic Kerberos authentication scheme, which relies on tickets to authenticate users and authorize access to services. A ticket is just an encrypted network message containing request and/or authentication data and credential expiration data (as we'll see).

Figure 7-1. Basic Kerberos 5 authentication

In the figure, the data passed between the user workstation (Kerberos client) and the various servers is depicted in the middle column of the drawing, passing between the two relevant computers. The legend describes the layout of this data. Included data is a darker shade, and the key used to encrypt it (if any) is indicated to its left, in the lighter shaded column. The sequence of events follows the circled numbers.

When a user logs in to a Kerberos-enabled workstation and enters his password, a one-way hash is computed from the password (1). This value is used as an encryption key within the Kerberos authentication request (2). The request consists of the unencrypted username and the current time; the time is encrypted using the hash created from the entered password (designated as K_P in the diagram). This is then sent to the Kerberos server, where its authentication function is invoked (3).

The Kerberos server knows the user's correct encoded password (which is not, in fact, stored on the workstation), so it can decrypt the time. If this operation is successful, the time is checked (to avoid replay attacks based on intercepted earlier communications). The server then creates a session key: an encryption key to be used for communicating with this client during the current session (which typically expires after about 8 hours). This is labeled as K_S1 in the diagram.

The Kerberos server also knows all the keys corresponding to its own services and services under its control. One of the former is the Kerberos Ticket Granting Service (TGS). Upon successful user authentication, the Kerberos server builds a response for the user (4). This transmission has two sets of data: the session key encrypted with the user password hash K_P, and a ticket-granting ticket (TGT) encrypted with the TGS's own key (designated K_TGS). The TGT contains another copy of the session key as well as user authentication data and time-stamps. The TGT will be used to request tickets for the actual services that the client wants to use. It can be thought of as a sort of meta-ticket: an authorization to request and receive actual tickets.

When the workstation receives this response (5), it decrypts the session key and stores it. It also saves the TGT in encrypted form (because it does not know the TGS's key).

The process of requesting access to a specific network service for example, a file access service begins at (6). The client builds a request for a ticket for the desired service to be sent to the Kerberos server's TGS. The request (7) contains the name of the desired service (unencrypted), the user information and current time encrypted with the session key, and the TGT.

The TGS can decrypt both parts of the message (8) because it knows both the session key and its own key (K_TGS). If the authentication is successful and the ticket's time is within the allowed window, the TGS creates a ticket for the client to use with the actual service (9). As part of this process, it generates another session key for use between the client and the target service (K_S2). The second service-specific session key is encrypted using the client's Kerberos server session key, K_S1, and the ticket to be supplied to the service is encrypted using the service's own key (designated K_V), which the Kerberos server also knows. The latter ticket consists of another copy of the new session key and user authentication and time-stamp data.

When the client receives this response (10), it decrypts the new session key using K_S1, and it stores the service ticket in encrypted form (because it does not know K_V). It presents the latter (11) to the desired server (12). The service decrypts it using its own key (K_V) and in doing so learns the session key to be used for future communication with the client (K_S2). Subsequent communications between the two rely solely on the latter session key.

As this description indicates, the Kerberos method assumes an untrustworthy network environment and encrypts all important data. Another nice feature is that it requires no action on the part of the user. All of the requests and ticket presentation happen automatically, triggered by the initial user login.

On the down side, Kerberos relies fundamentally on the security of the Kerberos server. If it is compromised, the security of the entire Kerberos infrastructure is at risk.