284 lines
14 KiB
HTML
284 lines
14 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
|
|
<TITLE>Linux Shadow Password HOWTO: Why shadow your passwd file?</TITLE>
|
|
<LINK HREF="Shadow-Password-HOWTO-3.html" REL=next>
|
|
<LINK HREF="Shadow-Password-HOWTO-1.html" REL=previous>
|
|
<LINK HREF="Shadow-Password-HOWTO.html#toc2" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="Shadow-Password-HOWTO-3.html">Next</A>
|
|
<A HREF="Shadow-Password-HOWTO-1.html">Previous</A>
|
|
<A HREF="Shadow-Password-HOWTO.html#toc2">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s2">2. Why shadow your passwd file?</A></H2>
|
|
|
|
<P>By default, most current Linux distributions do not contain the
|
|
<EM>Shadow Suite</EM> 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 <EM>Shadow Suite</EM> 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.
|
|
<P>The current maintainer of the <EM>Shadow Suite</EM>,
|
|
<A HREF="mailto:marekm@i17linuxb.ists.pwr.wroc.pl">Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl></A>
|
|
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.
|
|
<P>If you installed your distribution from a CD-ROM, you may find that, even
|
|
though the distribution did not have the <EM>Shadow Suite</EM> installed,
|
|
some of the files you need to install the <EM>Shadow Suite</EM> may be on
|
|
the CD-ROM.
|
|
<P><EM>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 <EM>suid
|
|
root</EM> programs that came with them, and should no longer be used.</EM>
|
|
<P>All of the necessary files may be obtained via anonymous FTP or through the
|
|
World Wide Web.
|
|
<P>On a Linux system without the <EM>Shadow Suite</EM> installed, user
|
|
information including passwords is stored in the <CODE>/etc/passwd</CODE> file.
|
|
The password is stored in an <EM>encrypted</EM> format. If you ask a
|
|
cryptography expert, however, he or she will tell you that the password
|
|
is actually in an <EM>encoded</EM> rather than <EM>encrypted</EM> 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 <EM>encoded</EM> in this
|
|
document.
|
|
<P>The algorithm used to encode the password field is technically
|
|
referred to as a <EM>one way hash function</EM>. 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.
|
|
<P>When a user picks or is assigned a password, it is encoded with a randomly
|
|
generated value called the <EM>salt</EM>. This means that any particular
|
|
password could be stored in 4096 different ways. The <EM>salt</EM> value
|
|
is then stored with the encoded password.
|
|
<P>When a user logs in and supplies a password, the <EM>salt</EM> is first
|
|
retrieved from the stored encoded password. Then the supplied password is
|
|
<EM>encoded</EM> with the <EM>salt</EM> value, and then compared with the
|
|
<EM>encoded</EM> password. If there is a match, then the user is
|
|
authenticated.
|
|
<P>It is computationally difficult (but not impossible) to take a randomly
|
|
<EM>encoded</EM> 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).
|
|
<P>System crackers know all this, and will simply encrypt a dictionary of
|
|
words and common passwords using all possible 4096 <EM>salt</EM> values.
|
|
Then they will compare the encoded passwords in your <CODE>/etc/passwd</CODE>
|
|
file with their database. Once they have found a match, they have the
|
|
password for another account. This is referred to as a <EM>dictionary
|
|
attack</EM>, and is one of the most common methods for gaining or expanding
|
|
unauthorized access to a system.
|
|
<P>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.
|
|
<P>Also, if a cracker obtains your <CODE>/etc/passwd</CODE> file first, they only
|
|
need to encode the dictionary with the <CODE>salt</CODE> values actually
|
|
contained in your <CODE>/etc/passwd</CODE> file. This method is usable by your
|
|
average teenager with a couple of hundred spare Megabytes and a 486 class
|
|
computer.
|
|
<P>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).
|
|
<P>The <CODE>/etc/passwd</CODE> file also contains information like user ID's and
|
|
group ID's that are used by many system programs. Therefore, the
|
|
<CODE>/etc/passwd</CODE> file <EM>must</EM> remain world readable. If you were
|
|
to change the <CODE>/etc/passwd</CODE> file so that nobody can read it, the
|
|
first thing that you would notice is that the <CODE>ls -l</CODE> command now
|
|
displays user ID's instead of names!
|
|
<P>The <EM>Shadow Suite</EM> solves the problem by relocating the passwords to
|
|
another file (usually <CODE>/etc/shadow</CODE>). The <CODE>/etc/shadow</CODE> file is set so
|
|
that it cannot be read by just anyone. Only <EM>root</EM> will be able to
|
|
read and write to the <CODE>/etc/shadow</CODE> 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 <EM>suid root</EM> or you can
|
|
set up a group <EM>shadow</EM> that is allowed read only access to the
|
|
<CODE>/etc/shadow</CODE> file. Then the program can be run <EM>sgid
|
|
shadow</EM>.
|
|
<P>By moving the passwords to the <CODE>/etc/shadow</CODE> file, we are effectively
|
|
keeping the attacker from having access to the encoded passwords with which
|
|
to perform a <EM>dictionary attack</EM>.
|
|
<P>Additionally, the <EM>Shadow Suite</EM> adds lots of other nice features:
|
|
<UL>
|
|
<LI>A configuration file to set login defaults (<CODE>/etc/login.defs</CODE>)</LI>
|
|
<LI>Utilities for adding, modifying, and deleting user accounts and groups</LI>
|
|
<LI>Password aging and expiration</LI>
|
|
<LI>Account expiration and locking</LI>
|
|
<LI>Shadowed group passwords (optional)</LI>
|
|
<LI>Double length passwords (16 character passwords) NOT RECOMMENDED]
|
|
<LI>Better control over user's password selection
|
|
<LI>Dial-up passwords
|
|
<LI>Secondary authentication programs [NOT RECOMMENDED]</LI>
|
|
</LI>
|
|
</LI>
|
|
</LI>
|
|
</UL>
|
|
<P>Installing the <EM>Shadow Suite</EM> 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.
|
|
<P>For current information on other Linux security issues, including warnings on
|
|
known vulnerabilities see the
|
|
<A HREF="http://bach.cis.temple.edu/linux/linux-security/">Linux Security home page.</A><P>
|
|
<P>
|
|
<H2><A NAME="ss2.1">2.1 Why you might NOT want to shadow your passwd file.</A>
|
|
</H2>
|
|
|
|
<P>There are a few circumstances and configurations in which installing the
|
|
<EM>Shadow Suite</EM> would <EM>NOT</EM> be a good idea:
|
|
<UL>
|
|
<LI>The machine does not contain user accounts.</LI>
|
|
<LI>Your machine is running on a LAN and is using NIS (Network Information
|
|
Services) to get or supply user names and passwords to other machines on
|
|
the network. (This can actually be done, but is beyond the scope of this
|
|
document, and really won't increase security much anyway)</LI>
|
|
<LI>Your machine is being used by terminal servers to verify users via NFS
|
|
(Network File System), NIS, or some other method.</LI>
|
|
<LI>Your machine runs other software that validates users, and there is no
|
|
shadow version available, and you don't have the source code.</LI>
|
|
</UL>
|
|
<P>
|
|
<P>
|
|
<H2><A NAME="ss2.2">2.2 Format of the /etc/passwd file</A>
|
|
</H2>
|
|
|
|
<P>A non-shadowed <CODE>/etc/passwd</CODE> file has the following format:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
username:passwd:UID:GID:full_name:directory:shell
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Where:
|
|
<DL>
|
|
<DT><B><CODE>username</CODE></B><DD><P>The user (login) name
|
|
<DT><B><CODE>passwd</CODE></B><DD><P>The encoded password
|
|
<DT><B><CODE>UID</CODE></B><DD><P>Numerical user ID
|
|
<DT><B><CODE>GID</CODE></B><DD><P>Numerical default group ID
|
|
<DT><B><CODE>full_name</CODE></B><DD><P>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.
|
|
<DT><B><CODE>directory</CODE></B><DD><P>User's home directory (Full pathname)
|
|
<DT><B><CODE>shell</CODE></B><DD><P>User's login shell (Full Pathname)
|
|
</DL>
|
|
|
|
For example:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
username:Npge08pfz4wuk:503:100:Full Name:/home/username:/bin/sh
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Where <CODE>Np</CODE> is the salt and <CODE>ge08pfz4wuk</CODE> is the <EM>encoded</EM>
|
|
password. The encoded salt/password could just as easily have been
|
|
<CODE>kbeMVnZM0oL7I</CODE> 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 <EM>bad</EM> password).
|
|
<P>Once the shadow suite is installed, the <CODE>/etc/passwd</CODE> file would
|
|
instead contain:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
username:x:503:100:Full Name:/home/username:/bin/sh
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
The <CODE>x</CODE> in the second field in this case is now just a place holder.
|
|
The format of the <CODE>/etc/passwd</CODE> file really didn't change, it just no
|
|
longer contains the <EM>encoded</EM> password. This means that any program
|
|
that reads the <CODE>/etc/passwd</CODE> file but does not actually need to verify
|
|
passwords will still operate correctly.
|
|
<P>The passwords are now relocated to the shadow file (usually
|
|
<CODE>/etc/shadow</CODE> file).
|
|
<P>
|
|
<H2><A NAME="ss2.3">2.3 Format of the shadow file</A>
|
|
</H2>
|
|
|
|
<P>The <CODE>/etc/shadow</CODE> file contains the following information:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
username:passwd:last:may:must:warn:expire:disable:reserved
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Where:
|
|
<DL>
|
|
<DT><B><CODE>username</CODE></B><DD><P>The User Name
|
|
<DT><B><CODE>passwd</CODE></B><DD><P>The Encoded password
|
|
<DT><B><CODE>last</CODE></B><DD><P>Days since Jan 1, 1970 that password was last changed
|
|
<DT><B><CODE>may</CODE></B><DD><P>Days before password may be changed
|
|
<DT><B><CODE>must</CODE></B><DD><P>Days after which password must be changed
|
|
<DT><B><CODE>warn</CODE></B><DD><P>Days before password is to expire that user is warned
|
|
<DT><B><CODE>expire</CODE></B><DD><P>Days after password expires that account is disabled
|
|
<DT><B><CODE>disable</CODE></B><DD><P>Days since Jan 1, 1970 that account is disabled
|
|
<DT><B><CODE>reserved</CODE></B><DD><P>A reserved field
|
|
</DL>
|
|
|
|
The previous example might then be:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
username:Npge08pfz4wuk:9479:0:10000::::
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>
|
|
<H2><A NAME="ss2.4">2.4 Review of crypt(3).</A>
|
|
</H2>
|
|
|
|
<P>From the crypt(3) manual page:
|
|
<P>"<EM>crypt</EM> is the password encryption function. It is based on
|
|
the <EM>Data Encryption Standard</EM> algorithm with variations intended (among
|
|
other things) to discourage use of hardware implementations of a key search.
|
|
<P>[The] key is a user's typed password. [The encoded string is all NULLs]
|
|
<P>[The] <EM>salt</EM> 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.
|
|
<P>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.
|
|
<P>
|
|
<B>Warning:</B> The key space consists of 2**56 equal 7.2e16 possible values.
|
|
Exhaustive searches of this key space <B>are possible</B> using massively
|
|
parallel computers. Software, such as <CODE>crack(1)</CODE>, 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 <CODE>passwd(1)</CODE> program that checks for
|
|
crackable passwords during the selection process is recommended.
|
|
<P>The DES algorithm itself has a few quirks which make the use of the
|
|
<CODE>crypt(3)</CODE> interface a very poor choice for anything other than
|
|
password authentication. If you are planning on using the <CODE>crypt(3)</CODE>
|
|
interface for a cryptography project, don't do it: get a good book on
|
|
encryption and one of the widely available DES libraries."
|
|
<P>Most <EM>Shadow Suites</EM> contain code for doubling the length of the
|
|
password to 16 characters. Experts in <CODE>des</CODE> 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 <CODE>crypt</CODE> works,
|
|
this may make for a <EM>less</EM> 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.
|
|
<P>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 <CODE>crypt</CODE> method.
|
|
<P>If you are looking for a good book on encryption, I recommend:
|
|
<PRE>
|
|
"Applied Cryptography: Protocols, Algorithms, and Source Code in C"
|
|
by Bruce Schneier <schneier@chinet.com>
|
|
ISBN: 0-471-59756-2
|
|
</PRE>
|
|
<P>
|
|
<P>
|
|
<HR>
|
|
<A HREF="Shadow-Password-HOWTO-3.html">Next</A>
|
|
<A HREF="Shadow-Password-HOWTO-1.html">Previous</A>
|
|
<A HREF="Shadow-Password-HOWTO.html#toc2">Contents</A>
|
|
</BODY>
|
|
</HTML>
|