Next Previous Contents

2. Why shadow your passwd file?

By default, most current Linux distributions do not contain the Shadow Suite installed. This includes Slackware 2.3, Slackware 3.0, and other popular distributions. One of the reasons for this is that the copyright notices in the original Shadow Suite were not clear on redistribution if a fee was charged. Linux uses a GNU Copyright (sometimes refereed to as a Copyleft) that allows people to package it into a convenient package (like a CD-ROM distribution) and charge a fee for it.

The current maintainer of the Shadow Suite, Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl> received the source code from the original author under a BSD style copyright that allowed redistribution. Now that the copyright issues are resolved, it is expected that future distributions will contain password shadowing by default. Until then, you will need to install it yourself.

If you installed your distribution from a CD-ROM, you may find that, even though the distribution did not have the Shadow Suite installed, some of the files you need to install the Shadow Suite may be on the CD-ROM.

However, Shadow Suite versions 3.3.1, 3.3.1-2, and shadow-mk all have security problems with their login program and several other suid root programs that came with them, and should no longer be used.

All of the necessary files may be obtained via anonymous FTP or through the World Wide Web.

On a Linux system without the Shadow Suite installed, user information including passwords is stored in the /etc/passwd file. The password is stored in an encrypted format. If you ask a cryptography expert, however, he or she will tell you that the password is actually in an encoded rather than encrypted format because when using crypt(3), the text is set to null and the password is the key. Therefore, from here on, I will use the term encoded in this document.

The algorithm used to encode the password field is technically referred to as a one way hash function. This is an algorithm that is easy to compute in one direction, but very difficult to calculate in the reverse direction. More about the actual algorithm used can be found in section 2.4 or your crypt(3) manual page.

When a user picks or is assigned a password, it is encoded with a randomly generated value called the salt. This means that any particular password could be stored in 4096 different ways. The salt value is then stored with the encoded password.

When a user logs in and supplies a password, the salt is first retrieved from the stored encoded password. Then the supplied password is encoded with the salt value, and then compared with the encoded password. If there is a match, then the user is authenticated.

It is computationally difficult (but not impossible) to take a randomly encoded password and recover the original password. However, on any system with more than just a few users, at least some of the passwords will be common words (or simple variations of common words).

System crackers know all this, and will simply encrypt a dictionary of words and common passwords using all possible 4096 salt values. Then they will compare the encoded passwords in your /etc/passwd file with their database. Once they have found a match, they have the password for another account. This is referred to as a dictionary attack, and is one of the most common methods for gaining or expanding unauthorized access to a system.

If you think about it, an 8 character password encodes to 4096 * 13 character strings. So a dictionary of say 400,000 common words, names, passwords, and simple variations would easily fit on a 4GB hard drive. The attacker need only sort them, and then check for matches. Since a 4GB hard drive can be had for under $1000.00, this is well within the means of most system crackers.

Also, if a cracker obtains your /etc/passwd file first, they only need to encode the dictionary with the salt values actually contained in your /etc/passwd file. This method is usable by your average teenager with a couple of hundred spare Megabytes and a 486 class computer.

Even without lots of drive space, utilities like crack(1) can usually break at least a couple of passwords on a system with enough users (assuming the users of the system are allowed to pick their own passwords).

The /etc/passwd file also contains information like user ID's and group ID's that are used by many system programs. Therefore, the /etc/passwd file must remain world readable. If you were to change the /etc/passwd file so that nobody can read it, the first thing that you would notice is that the ls -l command now displays user ID's instead of names!

The Shadow Suite solves the problem by relocating the passwords to another file (usually /etc/shadow). The /etc/shadow file is set so that it cannot be read by just anyone. Only root will be able to read and write to the /etc/shadow file. Some programs (like xlock) don't need to be able to change passwords, they only need to be able to verify them. These programs can either be run suid root or you can set up a group shadow that is allowed read only access to the /etc/shadow file. Then the program can be run sgid shadow.

By moving the passwords to the /etc/shadow file, we are effectively keeping the attacker from having access to the encoded passwords with which to perform a dictionary attack.

Additionally, the Shadow Suite adds lots of other nice features:

Installing the Shadow Suite contributes toward a more secure system, but there are many other things that can also be done to improve the security of a Linux system, and there will eventually be a series of Linux Security HOWTO's that will discuss other security measures and related issues.

For current information on other Linux security issues, including warnings on known vulnerabilities see the Linux Security home page.

2.1 Why you might NOT want to shadow your passwd file.

There are a few circumstances and configurations in which installing the Shadow Suite would NOT be a good idea:

2.2 Format of the /etc/passwd file

A non-shadowed /etc/passwd file has the following format: 

username:passwd:UID:GID:full_name:directory:shell
Where:
username

The user (login) name

passwd

The encoded password

UID

Numerical user ID

GID

Numerical default group ID

full_name

The user's full name - Actually this field is called the GECOS (General Electric Comprehensive Operating System) field and can store information other than just the full name. The Shadow commands and manual pages refer to this field as the comment field.

directory

User's home directory (Full pathname)

shell

User's login shell (Full Pathname)

For example: 
username:Npge08pfz4wuk:503:100:Full Name:/home/username:/bin/sh
Where Np is the salt and ge08pfz4wuk is the encoded password. The encoded salt/password could just as easily have been kbeMVnZM0oL7I and the two are exactly the same password. There are 4096 possible encodings for the same password. (The example password in this case is 'password', a really bad password).

Once the shadow suite is installed, the /etc/passwd file would instead contain: 

username:x:503:100:Full Name:/home/username:/bin/sh
The x in the second field in this case is now just a place holder. The format of the /etc/passwd file really didn't change, it just no longer contains the encoded password. This means that any program that reads the /etc/passwd file but does not actually need to verify passwords will still operate correctly.

The passwords are now relocated to the shadow file (usually /etc/shadow file).

2.3 Format of the shadow file

The /etc/shadow file contains the following information: 

username:passwd:last:may:must:warn:expire:disable:reserved
Where:
username

The User Name

passwd

The Encoded password

last

Days since Jan 1, 1970 that password was last changed

may

Days before password may be changed

must

Days after which password must be changed

warn

Days before password is to expire that user is warned

expire

Days after password expires that account is disabled

disable

Days since Jan 1, 1970 that account is disabled

reserved

A reserved field

The previous example might then be: 
username:Npge08pfz4wuk:9479:0:10000::::

2.4 Review of crypt(3).

From the crypt(3) manual page:

"crypt is the password encryption function. It is based on the Data Encryption Standard algorithm with variations intended (among other things) to discourage use of hardware implementations of a key search.

[The] key is a user's typed password. [The encoded string is all NULLs]

[The] salt is a two-character string chosen from the set [a-zA-Z0-9./]. This string is used to perturb the algorithm in one of 4096 different ways.

By taking the lowest 7 bit[s] of each character of the key, a 56-bit key is obtained. This 56-bit key is used to encrypt repeatedly a constant string (usually a string consisting of all zeros). The returned value points to the encrypted password, a series of 13 printable ASCII characters (the first two characters represent the salt itself). The return value points to static data whose content is overwritten by each call.

Warning: The key space consists of 2**56 equal 7.2e16 possible values. Exhaustive searches of this key space are possible using massively parallel computers. Software, such as crack(1), is available which will search the portion of this key space that is generally used by humans for passwords. Hence, password selection should, at minimum, avoid common words and names. The use of a passwd(1) program that checks for crackable passwords during the selection process is recommended.

The DES algorithm itself has a few quirks which make the use of the crypt(3) interface a very poor choice for anything other than password authentication. If you are planning on using the crypt(3) interface for a cryptography project, don't do it: get a good book on encryption and one of the widely available DES libraries."

Most Shadow Suites contain code for doubling the length of the password to 16 characters. Experts in des recommend against this, as the encoding is simply applied first to the left half and then to the right half of the longer password. Because of the way crypt works, this may make for a less secure encoded password then if double length passwords were not used in the first place. Additionally, it is less likely that a user will be able to remember a 16 character password.

There is development work under way that would allow the authentication algorithm to be replaced with something more secure and with support for longer passwords (specifically the MD5 algorithm) and retain compatibility with the crypt method.

If you are looking for a good book on encryption, I recommend: 

        "Applied Cryptography: Protocols, Algorithms, and Source Code in C"
        by Bruce Schneier <schneier@chinet.com>
        ISBN: 0-471-59756-2

Next Previous Contents

Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:58:11