Passwords Under Unix (Apache: The Definitive Guide)

5.3. Passwords Under Unix

Authentication of salespeople is managed by the password file users, stored in /usr/www/ok_users. This is safely above the document root, so that Bad Guys cannot get at it and mess with it. The file users is maintained using the Apache utility htpasswd . The source code for this utility is to be found in ... /apache_1.3.1/src/support/htpasswd.c, and we have to compile it with:

% make htpasswd

htpasswd now links, and we can set it to work. Since we don't know how it functions, the obvious thing is to prod it with:

% htpasswd -?

It responds that the correct usage is:

htpasswd [-c] passwordfile username
The -c flag creates a new file

This seems perfectly reasonable behavior, so let's create a user bill with the password "theft" (in real life, you would never use so obvious a password for such a character as Bill of the notorious Butterthlies sales team, because it would be subject to a dictionary attack, but this is not real life):

% htpasswd -c ... /ok_users/sales bill

We are asked to type his password twice, and the job is done. If we look in the password file, there is something like the following:

bill:$1$Pd$E5BY74CgGStbs.L/fsoEU0

Add subsequent users (the -c flag creates a new file, so we shouldn't use it after the first one):

% htpasswd ... /ok_users/sales ben

Carry on and do the same for sonia and daphne. We gave them all the same password, "theft," to save having to remember different ones later.

The password file ... /ok_users/users now looks something like this:[45]

[45]Note that this version of the file is as produced by export FreeBSD, so it doesn't use the more usual DES version of the crypt() function -- instead, it uses one based on MD5, so the password strings may look a little peculiar to you.

bill:$1$Pd$E5BY74CgGStbs.L/fsoEU0
ben:$1$/S$hCyzbA05Fu4CAlFK4SxIs0
sonia:$1$KZ$ye9u..7GbCCyrK8eFGU2w.
daphne:$1$3U$CF3Bcec4HzxFWppln6Ai01

Each username is followed by an encrypted password. They are stored like this to protect the passwords because, in theory at least, you cannot work backward from the encrypted to the plaintext version. If you pretend to be Bill and log in using:

$1$Pd$E5BY74CgGStbs.L/fsoEU0

the password gets reencrypted, becomes something like o09klks23O9RM, and fails to match. You can't tell by looking at this file (or if you can, we'll all be very disappointed) that Bill's password is actually "theft."


5.2. Authentication Directives		5.4. Passwords Under Win32