Linux and passwordJune 10, 2006
On a Linux system without the Shadow Suite installed, user information including passwords is stored in the
/etc/passwd file. Many people would say that 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).
/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 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:
- A configuration file to set login defaults (
- Utilities for adding, modifying, and deleting user accounts and groups
- Password aging and expiration
- Account expiration and locking
- Shadowed group passwords (optional)
- Double length passwords (16 character passwords) NOT RECOMMENDED
- Better control over user's password selection
- Dial-up passwords
- Secondary authentication programs
- Pluggable Authentication Modules (PAM) support
- Support for setting ulimits
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. For more Linux security issues and tips, see the Linux Security HOWTO.
There are a few circumstances and configurations in which installing the Shadow Suite would NOT be a good idea:
- Your distribution already contains shadow code. You should look in your
/etc/passwdfile and determine if passwords are actually being stored there. If you don't see any, try changing your password and look again. Many distributions come with accounts with no password.
- If you are running RedHat, you should use the RPM that is approporiate for your RedHat version to install shadow support. RedHat's shadow support is not the same as that documented here, so refer to RedHat's documentation
- If the machine does not contain any user accounts, then you probably don't need shadow support, unless you are installing it just to gain the experience.
- If 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 you would an NIS compatable shadow suite.. (This can actually be done, but is beyond the scope of this document, and should be done in conjunction with cryptographically secure software)
- If your machine is being used by terminal servers to verify users via NFS (Network File System), NIS, or some other method you probably can't shadow your system without breaking that software. If your terminal server supports RADIUS, that is probably your best solution.
- If your machine runs other software that validates users, and there is no shadow version available, and you don't have the source code you shouldn't install the Shadow Suite.
- If your machine is setup as a RADIUS server that authenticates users that are connecting to a terminal server. You actually can and should shadow a RADIUS server, but you will need a RADUIS server that has been patched to allow shadowed passwords. Both Livingston and Ascend have shadow support in their Radius servers. Some RADIUS servers have shadow support, but don't recognize the expired account and expired password fields.
/etc/passwd file has the following format:
The user (login) name
The encoded password
Numerical user ID
Numerical default group ID
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.
User's home directory (Full pathname)
User's login shell (Full Pathname)
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:
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 contains the following information:
The User Name
The Encoded password
Days since Jan 1, 1970 that password was last changed
Days before password may be changed
Days after which password must be changed
Days before password is to expire that user is warned
Days after password expires that account is disabled
Days since Jan 1, 1970 that account is disabled
A reserved field
The previous example might then be:
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 bits 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
If you are looking for a good book on encryption, I recommend:
"Applied Cryptography: Protocols, Algorithms, and Source Code in C"
by Bruce Schneier <email@example.com>
This section discusses some of the things that you will want to know now that you have the Shadow Suite installed on your system. More information is contained in the manual pages for each command.
The Shadow Suite added the following command line oriented commands for adding, modifying, and deleting users. You may also have installed the
useradd command can be used to add users to the system. You also invoke this command to change the default settings.
The first thing that you should do is to examine the default settings and make changes specific to your system:
The defaults are probably not what you want, so if you started adding users now you would have to specify all the information for each user. However, we can and should change the default values.
On my system:
- I want the default group to be 100
- I want passwords to expire every 60 days
- I don't want to lock an account because the password is expired
- I want to default shell to be
To make these changes I would use:
useradd -D -g100 -e60 -f0 -s/bin/bash
useradd -D will give:
Just in case you wanted to know, these defaults are stored in the file
Now you can use
useradd to add users to the system. For example, to add the user
fred, using the defaults, you would use the following:
useradd -m -c "Fred Flintstone" fred
This will create the following entry in the
And the following entry in the
fred's home directory will be created and the contents of
/etc/skel will be copied there because of the
Also, since we did not specify a UID, the next available one was used.
fred's account is created, but
fred still won't be able to login until we unlock the account. We do this by changing the password.
Changing password for fred
Enter the new password (minimum of 5 characters)
Please use a combination of upper and lower case letters and numbers.
New Password: *******
Re-enter new password: *******
/etc/shadow will contain:
fred will now be able to login and use the system. The nice thing about
useradd and the other programs that come with the Shadow Suite is that they make changes to the
/etc/shadow files atomically. So if you are adding a user, and another user is changing their password at the same time, both operations will be performed correctly.
You should use the supplied commands rather than directly editing
/etc/shadow. If you were editing the
/etc/shadow file, and a user were to change his password while you are editing, and then you were to save the file you were editing, the user's password change would be lost.
Here is a small interactive script that adds users using
# /sbin/newuser - A script to add users to the system using the Shadow
# Suite's useradd and passwd commands.
# Written my Mike Jackson <firstname.lastname@example.org> as an example for the Linux
# Shadow Password Howto. Permission to use and modify is expressly granted.
# This could be modified to show the defaults and allow modification similar
# to the Slackware Adduser program. It could also be modified to disallow
# stupid entries. (i.e. better error checking).
# Defaults for the useradd command
GROUP=100 # Default Group
HOME=/home # Home directory location (/home/username)
SKEL=/etc/skel # Skeleton Directory
INACTIVE=0 # Days after password expires to disable account (0=never)
EXPIRE=60 # Days that a passwords lasts
SHELL=/bin/bash # Default Shell (full path)
# Defaults for the passwd command
PASSMIN=0 # Days between password changes
PASSWARN=14 # Days before password expires that a warning is given
# Ensure that root is running the script.
if [ $WHOAMI != "root" ]; then
echo "You must be root to add news users!"
# Ask for username and fullname.
echo -n "Username: "
echo -n "Full name: "
echo "Adding user: $USERNAME."
# Note that the "" around $FULLNAME is required because this field is
# almost always going to contain at least on space, and without the "'s
# the useradd command would think that you we moving on to the next
# parameter when it reached the SPACE character.
/usr/sbin/useradd -c"$FULLNAME" -d$HOME/$USERNAME -e$EXPIRE \
-f$INACTIVE -g$GROUP -m -k$SKEL -s$SHELL $USERNAME
# Set password defaults
/bin/passwd -n $PASSMIN -w $PASSWARN $USERNAME >/dev/null 2>&1
# Let the passwd command actually ask for password (twice)
# Show what was done.
echo "Entry from /etc/passwd:"
echo -n " "
grep "$USERNAME:" /etc/passwd
echo "Entry from /etc/shadow:"
echo -n " "
grep "$USERNAME:" /etc/shadow
echo "Summary output of the passwd command:"
echo -n " "
passwd -S $USERNAME
Using a script to add new users is really much more preferable than editing the
/etc/shadow files directly or using a program like the Slackware
adduser program. Feel free to use and modify this script for your particular system.
For more information on the
useradd see the online manual page.
usermod program is used to modify the information on a user. The switches are similar to the
Let's say that you want to change
fred's shell, you would do the following:
usermod -s /bin/tcsh fred
/etc/passwd file entry would be change to this:
fred's account expire on 09/15/97:
usermod -e 09/15/97 fred
fred's entry in
For more information on the
usermod command see the online manual page.
userdel does just what you would expect, it deletes the user's account. You simply use:
userdel -r username
-r causes all files in the user's home directory to be removed along with the home directory itself. Files located in other file system will have to be searched for and deleted manually.
If you want to simply lock the account rather than delete it, use the
passwd command instead.
passwd command has the obvious use of changing passwords. Additionally, it is used by the root user to:
- Lock and unlock accounts (
- Set the maximum number of days that a password remains valid (
- Set the minimum days between password changes (
- Sets the number of days of warning that a password is about to expire (
- Sets the number of days after the password expires before the account is locked (
- Allow viewing of account information in a clearer format (
For example, let look again at
passwd -S fred
fred P 03/04/96 0 60 0 0
This means that
fred's password is valid, it was last changed on 03/04/96, it can be changed at any time, it expires after 60 days, fred will not be warned, and and the account won't be disabled when the password expires.
This simply means that if
fred logs in after the password expires, he will be prompted for a new password at login.
If we decide that we want to warn
fred 14 days before his password expires and make his account inactive 14 days after he lets it expire, we would need to do the following:
passwd -w14 -i14 fred
fred is changed to:
fred P 03/04/96 0 60 14 14
For more information on the
passwd command see the online manual page.
/etc/login is the configuration file for the
login program and also for the Shadow Suite as a whole.
/etc/login contains settings from what the prompts will look like to what the default expiration will be when a user changes his password.
/etc/login.defs file is quite well documented just by the comments that are contained within it. However, there are a few things to note:
- It contains flags that can be turned on or off that determine the amount of logging that takes place.
- It contains pointers to other configuration files.
- It contains defaults assignments for things like password aging.
From the above list you can see that this is a rather important file, and you should make sure that it is present, and that the settings are what you desire for your system.
/etc/groups file may contain passwords that permit a user to become a member of a particular group. This function is enabled if you define the constant
SHADOWGRP in the
If you define this constant and then compile, you must create an
/etc/gshadow file to hold the group passwords and the group administrator information.
When you created the
/etc/shadow, you used a program called
pwconv, there no equivalent program to create the
/etc/gshadow file, but it really doesn't matter, it takes care of itself.
To create the initial
/etc/gshadow file do the following:
chown root.root /etc/gshadow
chmod 700 /etc/gshadow
Once you create new groups, they will be added to the
/etc/group and the
/etc/gshadow files. If you modify a group by adding or removing users or changing the group password, the
/etc/gshadow file will be changed.
groupdel are provided as part of the Shadow Suite to modify groups.
The format of the
/etc/group file is as follows:
The name of the group
The field that normally holds the password, but that is now relocated to the
The numerical group ID number
List of group members
The format of the
/etc/gshadow file is as follows:
The name of the group
The encoded group password.
List of group administrators
List of group members
gpasswd is used only for adding or removing administrators and members to or from a group.
root or someone in the list of administrators may add or remove group members.
The groups password can be changed using the
passwd command by root or anyone listed as an administrator for the group.
Despite the fact that there is not currently a manual page for
gpasswd without any parameters gives a listing of options. It's fairly easy to grasp how it all works once you understand the file formats and the concepts.
pwck is provided to provide a consistency check on the
/etc/shadow files. It will check each username and verify that it has the following:
- the correct number of fields
- unique user name
- valid user and group identifier
- valid primary group
- valid home directory
- valid login shell
It will also warn of any account that has no password.
It's a good idea to run
pwck after installing the Shadow Suite. It's also a good idea to run it periodically, perhaps weekly or monthly. If you use the
-r option, you can use
cron to run it on a regular basis and have the report mailed to you.
grpck is the consistency checking program for the
/etc/gshadow files. It performs the following checks:
- the correct number of fields
- unique group name
- valid list of members and administrators
It also has the
-r option for automated reports.
Dial-up passwords are another optional line of defense for systems that allow dial-in access. If you have a system that allows many people to connect locally or via a network, but you want to limit who can dial in and connect, then dial-up passwords are for you. To enable dial-up passwords, you must edit the file
/etc/login.defs and ensure that
DIALUPS_CHECK_ENAB is set to
Two files contain the dial-up information,
/etc/dialups which contains the ttys (one per line, with the leading "/dev/" removed). If a tty is listed then dial-up checks are performed.
The second file is the
/etc/d_passwd file. This file contains the fully qualified path name of a shell, followed by an optional password.
If a user logs into a line that is listed in
/etc/dialups, and his shell is listed in the file
/etc/d_passwd he will be allowed access only by suppling the correct password.
Another useful purpose for using dial-up passwords might be to setup a line that only allows a certain type of connect (perhaps a PPP or UUCP connection). If a user tries to get another type of connection (i.e. a list of shells), he must know a password to use the line.
Before you can use the dial-up feature, you must create the files.
dpasswd is provided to assign passwords to the shells in the
/etc/d_passwd file. See the manual page for more information.