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:
/etc/login.defs)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.
There are a few circumstances and configurations in which installing the Shadow Suite would NOT be a good idea:
A non-shadowed /etc/passwd file has the following format:
username:passwd:UID:GID:full_name:directory:shell
usernameThe user (login) name
passwdThe encoded password
UIDNumerical user ID
GIDNumerical default group ID
full_nameThe 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.
directoryUser's home directory (Full pathname)
shellUser's login shell (Full Pathname)
username:Npge08pfz4wuk:503:100:Full Name:/home/username:/bin/sh
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
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).
The /etc/shadow file contains the following information:
username:passwd:last:may:must:warn:expire:disable:reserved
usernameThe User Name
passwdThe Encoded password
lastDays since Jan 1, 1970 that password was last changed
mayDays before password may be changed
mustDays after which password must be changed
warnDays before password is to expire that user is warned
expireDays after password expires that account is disabled
disableDays since Jan 1, 1970 that account is disabled
reservedA reserved field
username:Npge08pfz4wuk:9479:0:10000::::
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.
By taking the lowest 7 bit
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