The salt is a 12-bit random number chosen by the operating system. When the encryption algorithm is run, the bits of the salt are consulted to determine how some of the steps in DES should be altered. If a user happens to rely on the same password on different systems, a different salt will result in unique hashed values on the two systems. Similarly, if two users unknowingly choose the identical password on the same system, the cryptographic hash will be different. The salt is stored as the first two characters of the hashed password value in the shadow password file. Adding the salt means that a single cryptographic hash output value computed by an adversary cannot be compared to more than one entry in the password repository. Instead, the computed hash is potentially a match only for a single entry. This defense translates into an increase in the number of computations a hacker must perform when trying to crack passwords. More details of the UNIX cryptographic hash can be found in several references (Kaufman, Perlman, and Speciner, 1995; Garfinkel and Spafford, 1996).

The security of the UNIX password mechanism depends on several defenses. First, the password file is protected by the operating system using access control. Only limited privileged users can read the file. Next, the cryptographic technique used by UNIX to compute the hashed value is computationally infeasible to break. That is, based on public knowledge of the algorithm, you cannot decrypt the ciphertext value without the key or find the key given the ciphertext, even if the adversary has unlimited computing time.

Often, the phrase “unlimited computing time” is interpreted as “equal to the known life of the universe.” The source code for the password cryptography used by UNIX is readily available, and to date no accounts have been published of breaking the algorithm. Other threats and weaknesses exist, though, and these are discussed later in this chapter. For the moment, consider the next logical step. What happens if you have several users and several computers in a network?

Storing Passwords in a Central Server

Now that you understand the basic login procedure for UNIX, consider what happens if you have several computers in a network. If every user needs an account on each system, the network administrator will have a difficult time managing all of the accounts. Individual users will either need to keep their passwords synchronized across systems or use different passwords on each system. As the size of the network grows, these problems become increasingly complex. The solution is to provide an authentication server that contains all of the user, password, and group information in a database. Note that at this point all that is being suggested is a central store for the I&A information.

NIS and NIS+

Sun introduced the Network Information System (NIS) to act as a repository for I&A information and network configuration data to facilitate computing in a networked environment (Stern, 1991). NIS is configured on a chosen server to process information requests from clients. The NIS authentication database can be populated by importing the contents of /etc/passwd and other system files. Other NIS databases can be similarly initialized from standard system files.

By default, most UNIX operating system routines that handle I&A are modified to automatically work with NIS. Sun has licensed the implementation of NIS to other vendors for this purpose. That is, almost every major UNIX port includes NIS capabilities as part of the standard product. A configuration file can be modified to specify whether the local /etc/passwd file is to be searched before the NIS master database or vice versa. Notice that a user’s UID and GIDs will be established based upon this search order. If a username is found in both the local /etc/passwd file and in the NIS database, the first entry found will determine which UID is used to create the shell process. For performance and redundancy, NIS supports a primary or master server and one or more slave servers. Programs are provided for synchronizing slave databases from the master copies.

A simplified example will clarify the interactions during login. Assume that a network administrator has initialized an NIS server. A user now sits in front of a computer on the network. The computer could be the same as the NIS server, but assume that the computer is a completely different client system instead. The user enters a username and password in response to the login prompts as before. The client system controls these login prompts, not the NIS server. After the client’s login program has accepted the password, it computes the cryptographic hash as before, but instead of searching the local /etc/passwd file, the client sends a request to the NIS server for password verification. The password itself is never sent across the network, only the hashed value is included in the client’s request. The NIS server performs a lookup to verify whether the hashed value matches the corresponding value stored with the username in its database. The NIS server does not need to compute the password hash separately.

The original implementation of NIS has been criticized for several reasons. The password database was readable by anyone in the network. The ypcat command was available to dump the usernames and passwords for anyone interested. Access to the hash password values opens the system to attacks described later in this chapter, such as password guessing attacks. To circumvent this problem, Sun launched NIS+ so that passwords were kept in a shadow database, and only designated users would be allowed to access the information directly.

NIS+ also provides for encrypted network traffic between the clients and the NIS server. Even with shadowed passwords, an attacker could watch network traffic and try to capture NIS client-server exchanges. Because the hashed password is sent from the client to the server, over time the attacker would be able to obtain the equivalent of dumping the contents of the password database. If the traffic is encrypted, monitoring will succeed only if the cryptographic scheme can be cracked.