jim.shamlin.com

Password Protection

This form of access-restriction uses the built-in capabilities of HTTP, which is generally sufficient where the need for security is moderate (no acutely sensitive information is contained) ... though "moderate" and "sensitive" are matters of opinion and subject to much argument.

This technique utilizes built-in features of UNIX/Apache - when a user attempts to access a site in the restricted directory (or any subdirectory of it), a standard browser authentication dialog will appear, requesting the username and password to be entered in order to gain access.

Setting up HTTP restriction on a directory (and all subdirectories) is fairly straightforward: you'll need to create an upload two files (htaccess and htpasswd), and possibly a third (htgroup) if you need to manage an assortment of users and groups.

Worth mentioning: you also need to host with an ISP that will let you do this. Some ISPs don't allow this, as htaccess files can be misused or abused to do some things that can harm the stability or security of a server and they'd rather not deal with the consequences.

And of course, there are many subtleties I'm not addressing to cover the wide array of unusual things a person might want to do - this is just basic password protection, which will cover 99% of instances.


htaccess

The htaccess file (actually named .htaccess, with a leading period) is placed in the directory that you want to protect. It's content is:

AuthType Basic
AuthName Name_of_Restricted_Area
AuthUserFile /path/.htpasswd
AuthGroupFile /path/.htgroup

<Limit GET POST>
require username1
require username2
require group groupname1
</Limit>

Breaking that down even further ...

AuthType Basic

Use this as-is. I'm aware there are other values for the AuthType (such as "digest") but I've never had occasion to use them.

AuthName Name_of_Restricted_Area

This is optional, but generally useful, in that the dialog that asks for the username/password generally displays this string to inform the user what he's logging into.

AuthUserFile /path/.htpasswd

This specifies the path (from the root) to the password file (discussed in the next section).

AuthGroupFile /path/.htgroup

This specifies the path (from the root) to the group file. If you don't need to maintain user groups, just omit it.

<Limit GET POST>

To be honest, I've always used this, as shown, without digging into details. On occasion, I've removed "post" on a directory if there were no executables.

require username1

Use these lines, as many as needed, to specify the usernames (corresponding to the htpasswd file) that must be entered to gain access to the directory. You can also place multiple usernames on a single line, separated by spaces, like this:

require user1 user2 user3

I've never used that technique - seems a bit cluttered and hard to maintain, but it will certainly save the bytes from having repeated "require" at the beginning of each line.

require group groupname1

This line will provide restriction by group, as named in the htgroup file (documented later). I expect the same alternative of using spaces can be used here, but again, I generally don't do that.


htpasswd

The htpasswd file (again .htpasswd, with a leading period) contains the names of the users and their passwords, like this:

user1:dL0GU02VpDZYE
user2:o/1kJDAYWr3d2
user3:CRJj44r.st4xA

The user names are literal, but the passwords are encrypted to prevent anyone who accidentally gets hold of the file from being able to misuse passwords. (Actually, it's just a jerk hurdle, as decrypting passwords isn't that difficult once you've got the file.)

For that reason, it's a good idea to place htpasswd files in a directory that is not web-accessible (i.e., outside the document root), as low-rent miscreants can pretty easily find it and decrypt all the user's passwords.

As to how to encrypt passwords, that can be a bore, so I've developed a utility script to help: see it here.


htgroup

The htgroup file (again .htgroup, with a leading period) contains a list of groups and individual user names separated with spaces, thus:

groupname: user1 user2 user3 user4 user5

You will still need to use an htaccess file, as this contains only the user names. Also, the htgroup file doesn't contain anything that is much use to miscreants, but it's probably still a good idea to keep it out of the document root.

You don't have to use a htgroup file, and it most cases it's really not useful or necessary, and adds an extra task to your account maintenance routines.

As of the time of this writing, I've been working the Web for almost twenty years, and have had less than a dozen occasions in which it was useful. But on those occasions, it came in very handy.


Notes and Contingencies

A few loose notes:

Using The Server Config File

Some sources suggest it's safer to set up directory access restrictions in the server configuration file (httpd.conf). That's certainly true, but I avoid it. Besides being a colossal pain in the sack, making a simple mistake in the server configuration file has the potential to do some serious damage (at the very least, bring your server down) and since you'll probably need to maintain user accounts fairly often, it's not worth the risk of having to continually hack the configuration file.

Nested Directories

The htaccess file in a subdirectory will override one in its parent directory, which can be used to create increasing levels of permission. It can also be used to create a public directory within a password-protected one, though this seems a bit goofy, it may be necessary to overcome mistakes in planning.

Multiple htpasswd/htgroup Files

For sanity's sake, it's often useful to have a single password and group file for a server, but it's not necessary. If you have distinct groups with no person being a member of both, it may be efficient to have multiple ones. The pain begins when you have one person who needs access to two or more directories, and needs to be maintained in multiple locations (or required to use different usernames and/or passwords for each. I reccommend being very certain this won't happen before resorting to multiple password/group files.