|< Day Day Up >|
Where does Unix begin? At the password prompt, of course:
pua:~$ telnet host.example.edu Trying 18.104.22.168... Connected to host.example.edu Escape character is '^]'. SunOS 5.8 login: user Password:
This example demonstrates the password prompt for remote connection via telnet. Of course, you almost never use plain-text telnet nowadays, due to the threat of sniffing and session injection; Secure Shell (SSH) is a must-have . We did not even type the password while producing the above example, since we do not want the confidential information transmitted across the Internet or even the LAN in plain text. As this example shows, interaction with the Unix console begins with entering the username ”"user" in this instance ”and the password, which is never shown (for security reasons). However, this might not be exactly the case for remote connections, since public key cryptography can be used instead of a password. With SSH, for example, you can use regular password authentication: the password is transmitted over the wire in encrypted form and then verified by the server. The user who is trying to connect might need to enter a password in order for the client's SSH software to decrypt the private key. In the latter case, the password is never transmitted anywhere (even in the encrypted form) and is only used locally, to decrypt the private key from its encrypted storage.
The username identifies a separate environment (home directory) given to every authorized user and tracks objects (usually files) owned by the users. The system employs several usernames. "nobody" is typically used to run various processes, such as web servers, with as few privileges as possible. " root" in Unix is a privileged account with total control over a standard Unix system. Functions such as direct memory access, hardware access, process termination, and kernel patching are all within root's powers. In Unix, the username and password pair is used as a form of authentication. After a user enters a password, it is encrypted and compared to a string stored in a special file. In older versions of the operating system, the password was stored in the /etc/passwd file; in modern Unix systems, it's in /etc/shadow (or /etc/master.passwd and /etc/passwd , for NetBSD, FreeBSD, and OpenBSD). Consider the following example excerpted from a Solaris password file:
root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/adm: lp:x:4:7:lp:/var/spool/lpd: sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail: uucp:x:10:14:uucp:/var/spool/uucp: operator:x:11:0:operator:/root: games:x:12:100:games:/usr/games: gopher:x:13:30:gopher:/usr/lib/gopher-data: ftp:x:14:50:FTP User:/var/ftp: nobody:x:99:99:Nobody:/: user:x:500:500:Some User:/home/user:/bin/sh
As you can see, the file stores the username, encrypted  password or placeholder (in case shadow passwords are used), numeric user ID and group ID, user's real name , home directory, and preferred command interpreter (shell). This user ID gives the root user its superpowers: an account with UID = 0 is a superuser no matter what it is called on a particular computer.
The following example is a sample /etc/shadow file:
root:$Z/s45h83hduq9562jgpwj486nf83nr0:11481:0:99999:7::: bin:*:11348:0:99999:7::: daemon:*:11348:0:99999:7::: adm:*:11348:0:99999:7::: lp:*:11348:0:99999:7::: sync:*:11348:0:99999:7::: shutdown:*:11348:0:99999:7::: halt:*:11348:0:99999:7:::
It is important to note the presence of a password for root and the absence of such for other accounts. Accounts such as "daemon", "adm", and others are used not by real users, but rather by the system. The numbers after the usernames are related to password expiration and complexity policy.
The main difference between using /etc/passwd with encrypted passwords versus using a combination of /etc/passwd and /etc/shadow is that /etc/passwd must be readable for all users on a Unix system. Many programs use /etc/passwd to map usernames into numeric user IDs, determine real-life names based on username, and perform many other functions. Many of the programs that need access to /etc/passwd do not run with root privileges. Having the /etc/passwd file open can allow attackers to acquire the encrypted passwords and use a brute force attack to derive the plain-text versions.
The encrypted string in the previous example of the /etc/passwd file excerpt (in the "root" line) is not the actual encrypted password; rather, it is a block of data encrypted using a special encryption algorithm with the password as an encryption key. Classic Unix uses the DES algorithm, while several newer flavors, such as Linux, use MD5. The main difference between these algorithms is the strength of the cipher and the resulting length of the password. Since DES is a 56-bit cipher, the maximum useful key length does not exceed 8 characters . The password encryption program takes the lowest 7 bits of each of the first 8 characters of your password to construct a 56-bit key, which is used repeatedly in order to encrypt a string of zeros into a 14-character string present in the /etc/passwd file. Two random characters, or salt , are added to each password to increase randomness and confound a brute force attack that uses precomputed lists of encrypted strings. Thus, standard Unix passwords can only be eight characters or less. MD5, on the other hand, can theoretically support unlimited length. Some implementations of MD5 Unix passwords use 256 characters as a maximum length.
MD5 is known as a hash algorithm . It uses a one-way function, which results in theoretically undecipherable passwords, since the information is lost in the hashing process. These passwords can only be brute forced by trying various password strings and comparing them with the string obtained from the password file. It should also be noted that MD5 is more computation- intense than DES. Thus, brute force attacks take longer. However, the strength of the encrypted password depends on the choice of the unencrypted password. Since attackers possess huge lists of dictionary words in many languages (for some reason Unix passwords seem very susceptible to Star Trek word lists), it is dangerous to use a common word as a password.
In fact, using a dictionary word even as a part of your password is unwise. Several cracking programs, such as the classic tool known as John the Ripper, can transform a dictionary word by adding one or two numbers or special characters. Password-cracking libraries that can be used to stress-test the passwords (such as cracklib) also exist and might be integrated with Linux pluggable authentication modules. For example, after trying "dog", the program will try "dog12", "do!?g", and so on. This process usually finds a password much faster than simply trying random combinations of characters.
Conversely, if the system administrator enforces use of passwords like "jhf/i3:26g?w70f", users will invariably write them on Post-it notes stuck to their monitors , thus totally defeating the security of the password authentication. The best password is easy to remember, but difficult to guess. And even the best passwords need to be changed regularly. Some Unix systems (AIX, Linux, Solaris) use dubious proprietary extensions that enforce the length and the expiration time for all passwords and even keep a history of used passwords to prevent users from switching between two favorites. However, these extensions are not standard Unix and are not covered here.
Another file related to the user environment is /etc/group . This file defines users who belong to various groups. Here is an example of such a file from a modern Linux system:
root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon sys:x:3:root,bin,adm adm:x:4:root,adm,daemon tty:x:5: disk:x:6:root lp:x:7:daemon,lp mem:x:8: kmem:x:9: wheel:x:10:root mail:x:12:mail,postfix
The file contains group names and passwords (which are almost never used, so "x" serves as a placeholder) and lists group members .
Grouping users makes access control more flexible by allowing specific access levels (read, write, and execute) to the owner, group members, and other users. Grouping can also be used for authorization and in order to simplify system security administration.
Different Unix flavors use different files for storing such information. Table 11-1 provides a summary.
Table 11-1. Password files used by different Unix flavors
|< Day Day Up >|