Password-Protect Your Web Pages

Contents

1. Introduction
2. How Secure Is It?
3. The htpasswd program
4. Basic ByPassword Authentication: Step By Step
5. Multiple Usernames/Passwords
6. Most Common Problems & Solutions
7. For More Information

Introduction

This tutorial surveys the current methods for restricting access to documents stored on the CrossLink web server. The tutorial also walks through setup and use of these methods.

CrossLink allows access restriction based on several criteria:

• Username/password-level access authorization.
• Rejection or acceptance of connections based on Internet address of client.
• A combination of the above two methods.

This tutorial is based largely on the work done by the NCSA httpd development team.

How Secure Is It?

In Basic HTTP Authentication, the password is passed over the network not encrypted, but not as plain text either – it is "uuencoded." Anyone watching packet traffic on the network will not see the password in the clear, but the password will be easily decoded by anyone who happens to catch the right network packet.

So, basically this method of authentication is roughly as safe as telnet or ftp-style username and password security.

In MD5 Message Digest Authentication, the password is not passed over the network at all. Instead, a series of numbers is generated based on the password and other information about the request, and these numbers are then hashed using MD5. The resulting "digest" is then sent over the network, and it is combined with other items on the server to test against the saved digest on the server. This method is more secure over the network, but it has a penalty. The comparison digest on the server must be stored in a fashion that it is retrievable. Basic Authentication stores the password using the one way crypt() function. When the password comes across, the server uudecodes it and then crypts it to check against the stored value. There is no way to get the password from the crypted value. In MD5, you need the information that is stored, so you can't use a one way hashing function to store it. This means that MD5 requires more rigorous security on the server machine. It is possible, but non-trivial, to implement this type of security under the Unix™ security model.

MD5 Message Digest Authentication is not covered in this document.

The htpasswd program

You should use the htpasswd program to create the ID and Password files used by the web server. This is available by telneting to the server and running htpasswd. If you do not have unix shell access to the web server (individual and corporate lite accounts) or do not want to log into the web server, unsupported DOS and Windows versions of htpasswd are available. (They work to the best of our knowledge, but we are only able to provide support for the Unix shell version.) The htpasswd program's use is documented below.

Basic ByPassword Authentication: Step By Step

This should help you set up protection on a directory via the Basic HTTP Authentication method. This method also uses the standard plain-text password file. If you have a large user base, NCSA HTTPd supports a DBM based password file for faster access.

So let's suppose you want to restrict files in a directory called turkey to username pumpkin and password pie. Here's what to do:

Create a file called .htaccess in directory turkey that looks like this:

AuthUserFile /home/corp/johndoe/.htpasswd
AuthGroupFile /dev/null
AuthName ByPassword
AuthType Basic
<Limit GET>
require user pumpkin
</Limit>

Note that the password file will be in another directory (/home/corp/johndoe).

AuthUserFile must be the full Unix pathname of the password file.

Also note that in this case there is no group file, so we specify /dev/null (the standard Unix way to say "this file doesn't exist").

AuthName can be anything you want. The AuthName field gives the Realm name for which the protection is provided. This name is usually given when a browser prompts for a password, and is also usually used by a browser in correlation with the URL to save the password information you enter so that it can authenticate automatically on the next challenge. Note: You should set this to something, otherwise it will default to "ByPassword," which is both non-descriptive and too common.

AuthType should be set to Basic, since we are using Basic HTTP Authentication. Other possibilities are PEM, PGP, KerberosV4, KerberosV5, or Digest. These other types of authentication will be discussed later.

In this example, only the method GET is restricted using the LIMIT directive. To limit other methods (particularly in CGI directories), you can specify them separated by spaces in the LIMIT directive. For example:

<LIMIT GET POST PUT>
require user pumpkin
</LIMIT>

If you only use GET protection for a CGI script, you may be finding that the REMOTE_USER environment variable is not getting set when using METHOD="POST", obviously because the directory isn't protected against POST.

Create the password file: /home/corp/johndoe/.htpasswd.

The easiest way to do this is to use the htpasswd program distributed with NCSA HTTPd. Do this:

htpasswd -c /home/corp/johndoe/.htpasswd pumpkin

Type the password – pie – twice as instructed.

Check the resulting file to get a warm feeling of self-satisfaction; it should look like this:

pumpkin:y1ia3tjWkhCK2

That's all. Now try to access a file in directory turkey – your browser should demand a username and password, and not give you access to the file if you don't enter pumpkin and pie. If you are using a browser that doesn't handle authentication, you will not be able to access the document at all.

Multiple Usernames/Passwords

If you want to give access to a directory to more than one username/password pair, follow the same steps as for a single username/password with the following additions:

Add additional users to the directory's .htpasswd file.

Use the htpasswd command without the -c flag to add additional users; e.g.:

htpasswd /home/corp/johndoe/.htpasswd peanuts
htpasswd /home/corp/johndoe/.htpasswd almonds
htpasswd /home/corp/johndoe/.htpasswd walnuts

Create a group file.

Call it /home/corp/johndoe/.htgroup and have it look something like this:

my-users: pumpkin peanuts almonds walnuts

... where pumpkin, peanuts, almonds, and walnuts are the usernames.

Then modify the .htaccess file in the directory to look like this:

AuthUserFile /home/corp/johndoe/.htpasswd
AuthGroupFile /home/corp/johndoe/.htgroup
AuthName ByPassword
AuthType Basic

<Limit GET>
require group my-users
</Limit>

Note that AuthGroupFile now points to your group file and that group my-users (rather than individual user pumpkin) is now required for access.

That's it. Now any user in group my-users can use his/her individual username and password to gain access to directory turkey.

Most Common Problems & Solutions

Use Full Path Names

When specifying the AuthUserFile and AuthGroupFile, you must use the full path name on the web server; i.e. use "AuthUserFile /home/corp/johndoe/.htpasswd" not "AuthUserFile .htpasswd".

Use the IP Address not the Domain Name

The CrossLink web server does not resolve the domain names of the computers connecting to it. As a result, when using allow from or deny from directives, you must use the IP address.

For More Information

• W3C on HTTP-based Authentication