This tutorial surveys the current methods for restricting access to documents stored on the Why? InterNetworking web server. The tutorial also walks through setup and use of these methods.
Why? InterNetworking allows access restriction based on several criteria:
This tutorial is based largely on the work done by the NCSA httpd development team.
In Basic HTTP Authentication, the password is passed over the network not encrypted but not as plain text -- 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
telnet or ftp style username and
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
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 UnixTM
MD5 Message Digest Authentication is not covered in this document.
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.
This should help you set up protection on a directory via the Basic HTTP Authentication method. This method also uses the standard plaintext 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
turkey to username
pie. Here's what to do:
.htaccess in directory
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
/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
AuthType should be set to
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
directive. To limit other methods (particularly in CGI
directories), you can specify them separated by spaces in the
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
variable is not getting set when using
obviously because the directory isn't protected against
the password file /home/corp/johndoe
The easiest way to do this is to use the
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:
That's all. Now try to access a file in directory
-- your browser should demand a username and password, and not
give you access to the file if you don't enter
pie. If you are using a browser that doesn't
handle authentication, you will not be able to access the
document at all.
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:
additional users to the directory's
htpasswd command without the
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
and have it look something like this:
my-users: pumpkin peanuts almonds walnuts
walnuts are the usernames.
.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>
AuthGroupFile now points to your group
file and that group
my-users (rather than individual
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
Following are several examples of the range of access authorization capabilities available through the Why? InterNetworking web server. The examples are served from a system at NCSA (University of Illinois).
There is no correspondence between usernames and
passwords on specific Unix systems (e.g. in an
file) and usernames and passwords in the authentication
schemes we're discussing for use in the Web. As
illustrated in the examples, Web-based authentication
uses similar but wholly distinct password files; a
user need never have an actual account on a given Unix
system in order to be validated for access to files being
served from that system and protected with HTTP-based
for non-NCSA readers: The
used in this case is as follows:
AuthUserFile /dev/null AuthGroupFile /dev/null AuthName ExampleAllowFromNCSA AuthType Basic <Limit GET> order deny,allow deny from all allow from
Note for NCSA readers: The
file used in this case is as follows:
AuthUserFile /dev/null AuthGroupFile /dev/null AuthName ExampleDenyFromNCSA AuthType Basic <Limit GET> order allow,deny allow from all deny from
Use Full Path Names
When specifying the
you must use the full path name on the web server. I.e. use
Use the IP Address not the Domain Name
The Why? InterNetworking web server does not resolve the domain names of the
computers connecting to it. As a result, when using
deny from directives, you must use
the IP address.