Navigation

Home

 

Web Essentials

 

Tutorial - Securing your Web Pages with Password Security and/or Client Access Restriction

for Cal Poly Faculty, Staff, and Students.

Credit: This tutorial borrows heavily from the NCSA tutorial at http://hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html, and has been
tailored for the APACHE web server which is the Cal Poly Central UNIX web server. Please note that ITS does not provide direct support assistance for setting up this feature on user's accounts.

Introduction

This tutorial will show you how to use .htaccess files on your Central UNIX account to restrict access to Web files by setting password protection to your web pages. Apache .htaccess files allow 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.

Tutorial Contents

This tutorial is accompanied by a troubleshooting guide to assist you with any difficulties setting up your Web pages with password security.

Getting Started

A common need is to cause the Web server to handle all the documents in a particular directory, or tree of directories, in the same way -- such as requiring a password before granting access to any file in the directory, or allowing/disallowing directory listings. This tutorial shows you how to use per-directory configuration files, called .htaccess files, to apply password protection to your Web files.

However, you must have both a UNIX account and Web pages contained within your public_html directory before you can use the .htaccess files. Cal Poly has more information on how to make a Web Page and you can use the My.CalPoly Portal to to "activate your account" on Central UNIX.

General Information

There are two levels at which authentication information can be passed to the server: the global access configuration file and the per-directory configuration files. This tutorial covers per-directory configuration. See the NCSA HTTPd documentation for information on global configuration.

Per-directory configuration means that users with write access to part of the file system that is being served (the Document Tree) can control access to their files as they wish. They do not need to have root access on the system or write access to the server's primary configuration files. Also, the per-directory configuration files are read and parsed by the server on each access, allowing run-time reconfiguration. The global configuration files are only parsed on startup or restart, which usually requires root authority. There is a speed penalty associated with using the per-directory configuration files, but that's the tradeoff you have to take.

Access control for a given directory is controlled by a specific file in the directory with a filename as specified by the AccessFileName directive. The default filename is .htaccess.

How Secure Is It?

In Basic HTTP Authentication, the password is uuencoded and passed over the network. 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.

Basically, this method of authentication is roughly as safe as telnet-style username and password security -- if you trust your machine to be on the Internet, open to attempts to telnet in by anyone who wants to try, then you have no reason not to trust HTTP Authentication.

Basic .htaccess Authentication: Step By Step

(This tutorial is accompanied by a troubleshooting guide to assist you with any difficulties setting up Web pages with password security.)

This tutorial should help you set up protection on a directory via the Basic HTTP Authentication method and a standard plain text password file.

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

In the turkey directory, use pico or vi editor to create a file called .htaccess that looks like this:

AuthUserFile /private/.htpasswd
AuthGroupFile /dev/null
AuthName ByPassword
AuthType Basic

<Limit GET>
require user pumpkin
</Limit>

Note that the password file will be in another directory /private/.

AuthUserFile must reference the full UNIX pathname of the .htpasswd file. You can determine the full UNIX pathname by typing the following at the percent prompt in the directory that the password file will be saved in (in this case the directory is private).

% pwd

Also note that 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.

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>

In the home directory /private/, create the .htpasswd password file. The /private/ directory is the directory you identified above in the AuthUserFile.

The easiest way to do this is to use the htpasswd program that follows:

% htpasswd -c /private/.htpasswd pumpkin

Type the password -- pie -- twice as instructed.

Check the resulting .htpasswd file in pico to see if your password was created properly. It should look similar to the following:

pumpkin:y1ia3tjWkhCK2

You must also set the proper permissions of the files and folders you created. Check the permissions of the .htaccess files, .htpasswd files and the directory where the .htpasswd file exists. If they are incorrect, type the following:

for incorrect .htaccess directory (turkey) and .htpasswd directory permissions, type:

% chmod og+x turkey
% chmod og+x private

for incorrect .htaccess and .htpasswd file permissions, type:

% chmod og+r .htaccess
% chmod og+r .htpasswd

That's all. Now try to access a file in the turkey directory. Your browser should demand a username and password, and deny you access to the file if they are incorrect. If you are using a browser that does not handle authentication, you will not be able to access the document at all.

Refer to the troubleshooting guide sections below if you have any problems setting up Web pages with password security. (NOTE: These links point to another document).

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 /private/.htpasswd peanuts
htpasswd /private/.htpasswd almonds
htpasswd /private/.htpasswd walnuts

Create a group file.

Call it /private/.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 /private/.htpasswd
AuthGroupFile /private/.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.

Prepared Examples

Following are examples of the range of access authorization capabilities available. The examples are served from a system at NCSA.

Simple protection by password.

This document is accessible only to user fido with password bones.

Important Note: There is no correspondence between usernames and passwords on specific UNIX systems (e.g. in an /etc./passwd 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 authentication.

Protection by password; multiple users allowed.

This document is accessible to user "rover" with password "bacon" and user "jumpy" with password "kibbles".

Protection by network domain.

http://hoohoo.ncsa.uiuc.edu/examples/auth/by-domain-not-ncsa/access-me.html is only accessible to clients running on machines inside domain ncsa.uiuc.edu.

Note for non-NCSA readers: The .htaccess file 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 .ncsa.uiuc.edu
</Limit>

Protection by network domain -- exclusion.

This document is accessible to clients running on machines anywhere but inside domain ncsa.uiuc.edu.

Note for NCSA readers: The .htaccess 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 .ncsa.uiuc.edu
</Limit>


This tutorial borrows heavily from the NCSA tutorial at http://hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html, and has been tailored for the APACHE web server.