If you want an example of evolution in action, look at the GNU/Linux password system. Although it includes the basic UNIX password structure as a vestigial organ, natural selection in the form of crackers has forced the evolution of shadow passwords, the MD5 algorithm and PAM. Passwords have even found new niches in the form of boot managers, remote login formats and advanced security systems. All these tools are used daily, but by taking a closer look at them, you can use them to make your system a little more secure.
Back in the Jurassic days of the 1970s, the standard UNIX password structure appeared. Nowadays, many users access it graphically through gdm, otherwise its structure hasn't changed much. To log in to an account, users enter a password of up to eight characters (it was six or seven in the past), and the password is encrypted into a key using the DES (data encryption standard) algorithm. This key is stored in the second column /etc/passwd, where any user can view it.
What has changed is the competition. Nowadays, the DES algorithm can be cracked in seconds. And, to make matters worse, there's little choice in the standard structure except to store the key for each password in a public place, where any intruder can find it. The alternative is to place severe restrictions on ordinary users and prevent them from using basic commands like ls -l. Although some security experts would be happy with a computer that was turned off and left in a lead-lined vault several miles beneath the surface of the earth, these restrictions are largely unacceptable.
By the mid-1990s, with the Internet's popularity giving crackers more opportunities, the competition was becoming intense. Because of this pressure, defenses began to evolve. At first available only as add-ons, by the dawn of modern times in the late nineties, these defenses were in symbiotic relations with each other and were standard parts of every distribution.
Shadow passwords get their name because they are the hidden counterparts of basic passwords. The difference is that, instead of being native to a public file like /etc/passwd, their habitat is the second column of /etc/shadow, a file readable only by the root user. If no password is set for an account, the column is marked by an asterisk or an exclamation mark, depending on the distribution. Only an “x” in the password column of /etc/passwd is left to mark their passage.
Since shadow passwords have been standard, manual configuration has all but disappeared. All the same, shadow passwords generally come with a toolset. pwconv and grpconv keep user and group entries in /etc/shadow and /etc/passwd in sync, but this housekeeping is generally done automatically when a password is created for the account. Similarly, pwunconv and grpunconv allow the creation of regular passwords, but few modern systems ever require this devolution. About the only useful shadow password tool is Debian's shadowconfig, whose on-and-off options can tell you quickly whether shadow passwords are enabled.
Another evolutionary dead end is the set of additional columns in /etc/shadow. Superficially, these columns promise extra control over when passwords are changed, when warnings of the need to change are given and when an account is disabled if its password is not changed. These columns could be a major survival trait. Unfortunately, they have to be entered individually for each user. More importantly, they must be entered in days since January 1, 1970. This measurement is so cumbersome to calculate that many system administrators leave most of the columns blank and fill the rest with impossibly large numbers so they can ignore them.
Another adaptation of the basic password structure is the use of the MD5 encryption algorithm. MD5 is the latest in an evolutionary line of algorithms developed by Ronald Rivest, an MIT professor and a founder of RSA Security, the dominant company in encryption for over a decade. It is a descendant of MD2, an algorithm optimized for 8-bit machines, and a modification of MD4, an algorithm for 32-bit machines that Rivest and his collaborators felt was rushed into release. First released to the public domain in 1991, MD5 was further modified in 1994.
Today, MD5 remains a standard in authentication, even though Rivest insists that it was never intended for that use. More elaborate algorithms have been developed in recent years, such as IDEA, Skipjack or Bowfish, but none has been proven to outperform MD5 consistently enough to replace it.
MD5 became available as an add-on for GNU/Linux in the mid-nineties and is a now a standard part of most distributions. From a security perspective, the advantages of MD5 over the DES used in the standard password structure is that it allows for longer passwords and provides more sophisticated encryption. When MD5 is enabled, passwords of up to 256 characters are possible. Regardless of the password's actual length, MD5 passes it through four rounds of encryption to create a 256-character key. Since this process is not reversible (at least, not without considerable effort), MD5 is classified as a “one-way hash”.
MD5 is an option during the installation of every major distribution. Although MD5 can create problems with network information systems on most modern workstations or networks, there is no reason not to use it. If you are unsure whether MD5 is enabled, check whether the password column in /etc/shadow starts with $1$, or search the files in /etc/pam.d for lines that end in “md5”. If it isn't, locating the necessary files and reconfiguring the system is time-consuming enough that a new user might be tempted to upgrade or re-install instead.
The rise of shadow passwords and MD5 could potentially cause over-diversification, with every combination of add-ons requiring its own versions of commands like passwd or login. This problem is avoided by the Pluggable Authentication Method (PAM). PAM can be thought of as an intermediary between the commands and processes involved with authentication and any modifications to it. PAM evolved along with shadow passwords and MD5 and has been available in distributions since about 1997.
Originally, PAM was configured in /etc/pam.conf. However, in most distributions, this file is now as vestigial as an appendix. Instead, PAM uses the /etc/pam.d directory.
A handful of files in /etc/pam.d define which users or groups, if any, can use a specific command. For example, /etc/pam.d/su regulates the su command. Other limits may be set in /etc/security/limits.conf. However, the majority of the files in /etc/pam.d act as intermediaries between password system enhancements and other commands, pointing to libraries in /lib/security. Examples of these files include chfn, chsh, cron, gdm and login. This function allows not only the use of shadow passwords or MD5 but eases the addition of upscale security solutions such as Kerebos.
The files in /etc/pam.d offer far too many options to detail here. However, the files are heavily commented and relatively easy to follow. Files such as passwd, gdm, login and su, which control the basics of the password system, are especially useful. For example, login can control root logins, put a time restraint on logins and set how login attempts are logged. Similarly, if you use su on the system, rather than the more controllable sudo, /etc/pam.d/su can help you set limits on how the command is used. And, while you don't want to change the references to security libraries in the pam.d files, you might want to look at the options used with them—for instance, the security-minded might want to avoid nullok, which allows users to change empty passwords. Going farther afield, chsh can be used to limit the shells users can use to a list in /etc/shells. In short, while browsing the pam.d directory can leave you with the trauma of option anxiety, you'll find the effort an important step in learning how to make your system more secure.
Shadow passwords, MD5 and PAM all increase the security of a system. However, keep in mind that the security they provide is relative. Given enough computing power and enough time, a brute-force attack can crack any system.
Moreover, the effort is getting easier with each advance in hardware and crackers' tools. To put things in perspective, in 1994, RSA Security system estimated that a brute-force attack on the average machine would succeed within 24 days. By contrast, the developers of mdcrack, a tool that can be used for testing the security of MD5-enabled systems, claim that a 56-character password can be cracked on an average machine using the 2.2 Linux kernel within 20 seconds. Although that was almost twice as long as the average time to crack a Windows machine, obviously Linux users have no reason to be smug. And the situation is only going to get worse.
One way to respond to this pressure is to make better use of the password system. Many users, especially at home, forget about the password system after they install and fail to use anything except its most basic features. Yet a little attention to detail could be enough to send the script kiddies into tantrums. For example:
Set the number of days that a password can be used in /etc/shadow. The method is a pain, but regularly changed passwords could set back a brute-force attack that relies more on time than computing power.
Increase the minimum and maximum password lengths in /etc/pam.d/passwd. Other things being equal: the longer the password, the longer it takes to crack.
Lower the minimum number of login attempts in /etc/pam.d/gdm. Legitimate users with sausage-like fingers might complain, but anyone attempting a brute-force attack could be irritated enough to go away.
Approve all user passwords or insist that they are generated by a program like pwgen that creates secure passwords. The number of users whose password is “password” or the name of their youngest daughter or goldfish is too depressing for words.
Install a program like cracklib2, which prevents the use of easily guessed passwords. You'll probably want to add a custom dictionary of company, product and user names that cannot be used as passwords. Currently, cracklib2 requires some patience to set up, as well as the uncommenting of a number of lines in /etc/pam.d, but it, or a similar package, is likely to become a standard part of major distributions in the next few years.
Do not allow the root user to log in remotely.
Watch for expired passwords or user accounts without passwords. Either could be an entry point to the system.
Turn off your computer or your net connection if you're not using it. Forget the geek macho about how long your system has been running. If it's not connected, then remote cracks can't happen.
Another response to the increased risks of modern computers is the increased use of password authentication on the system. Here are some of the places you can add passwords if they aren't already there:
The BIOS: use a password and make sure it can't be bypassed via floppy or CD.
The Boot Manager: use LILO's password command or GRUB's lock command.
Remote Services: ssh sends encrypted passwords—Telnet and FTP don't. Guess which one you should use?
Still, there's no reason not to use whatever security passwords afford. And there's definitely not a reason to bypass the password system or weaken it—two options that are starting to appear in modern distributions in the hopes of making GNU/Linux seem more like other operating systems of the average user's acquaintance. The tools are there, so why not use them?
