Secure Web Folders

.htaccess Files

A .htaccess (dot-htaccess) file contains directives (commands) executed by the server before it delivers files to a browser. Some of the most common use for the .htaccess file is Controlling access to web documents by password or IP address.

Scope of the .htacess File
If you create a .htaccess file for one of your web directories, the effects from that file will be applied to all of the files in that directory and all subdirectories within that directory UNLESS you create a separate .htaccess file for that subdirectory.  For example, if your main directory is called ‘Too’ and you have a .htaccess file that defines files with a ‘.htm’ extension to be given the MIME type ‘text/plain’, but you have a subdirectory called ‘Far’ which you want files with a ‘.htm’ extension to be given the MIME type ‘text/html’, you will need to create a separate .htaccess file for the ‘Far’ directory.

Controlling Access to Web Pages

  • Allow/Deny Access
  • Username/Password Access
  • Combining both types of restriction

Web Servers by default allow anyone to view any document residing in your public_html (or html) directory and it’s sub-directories. There is a way to tell the Web Server to restrict access to these pages by using Server directives (commands).

Access can be restricted in two ways:

  • By IP address, and/or
  • With a valid user name and password.

These methods can be used separately or together.

Restricting or granting access based on the visitor’s IP address allows you to specify an exact IP address or a domain (example.com). Complete details on IP resricting is covered in the Allow/Dent Access section. Password protecting your site or portions of your Web Site requires you read this entire page.

.htaccess Information

First let’s be clear, you can not control access of an individual file without totally restricting it’s access using file permissions. You can control the access of groups of files or stated more clearly directories. If there are files you want to protect they need to be placed in a separate directory (/restricted). The next step to protecting the /restricted directory is the placement of a server directive in an .htaccess file stored in that directory (/restricted). We will outline the use of the .htaccess file to protect your sensitive data.NOTE: the .htaccess restrictions only restricts directory access through the Web, if you share FTP access to your account you can access the ‘restricted’ directories.

Allow/Deny Access

There are four directives used to control access:

  • Order,
  • Deny,
  • Allow, and
  • Require.
Order:
Dictates the order the allow and deny operations are executed. The syntax of the Order directive are separated by a coma with NO SPACES between them. The arrangement of the allow and deny specifies the order in which they will be executed. You determined the order based on how you intend to restrict access. There are two main approaches, restrict everyone and list the computer’s (IP’s) that can access OR let evryone access and list the computer’s (IP’s) you do not want to access your files.

FOR EXAMPLE:
If you only want computer’s within IP_address to access your files then the .htaccess file would look like this:

order deny,allow
deny from all
allow from 173.11.24.56

If you wanted to allow access to everyone except IP_address users the .htaccess file would look like:

order allow,deny
allow from all
deny from 173.11.24.56

The Order directive has a mutual-failure feature meaning that if the Order directive is used then the following rules apply.

  • Any computer on the allow list is allowed
  • Any computer on the deny list is denied
  • any computer not listed on either the allow or deny list is automatically denied.
Deny:
This directive is used to deny access to a directory in one of the following three ways:

Full IP address
deny from 137.99.29.255
partial IP addresses (for denying access to subnets)
deny from 137.99
or the all keyword
deny from all
Allow
This directive can be specified in the same manner the deny directive.
Require
This directive is used to restrict access to specific users and groups of users.

users:
require user username
group:
require group groupname

Note: Here ‘username’ refers to a specific user in a password file. The groupname refers to a group that has been created in a group file. Refer to Username/Password Access for details on creating users and groups.

IMPORTANT: It is escential to include a hard return after the last line of the .htaccess file. Failure to do so may result in problems with your .htaccess file.

Recursive

The restrictions that the .htaccess file places on a directory is recursive. Meaning that the file restrictions apply to ALL sub-directories unless a .htaccess file is placed in the sub-directory to override the recursive nature of the .htaccess file.

Username/Password Access

Setting up password protection requires two steps:

  • Create a password file using the htpasswd program
  • Create (or modify) an .htaccess file to work with the password file

Using htpasswd
htpasswd is a UNIX utility used to create user name and passwords for use in authenticating access to a directory (under the public_html directory).

htpasswd is used as follows:

htpasswd [-c] password_file username

The -c option flag is only used the first time as it creates the password file and subsequent use will delete any existing password file and replace it with a new one. If you have previously created a password file simply do not use the -c option flag.

password_file refers to the pathway and name of the file you will use to store your password information in. username is pretty self-explanatory, if you don’t get it here’s a hint (HINT: look in a mirror or at a picture of the person you are creating the account for.). There are no restrictions on the name you give the password file, however, the accepted convention is .htpasswd.

Example:
To create a password file named .htpasswd in a directory ‘/public_html/restricted’ for a user named ‘guest’, you would type the following:

htpasswd -c /public_html/restricted/.htpasswd guest

Once you hit enter, you will be prompted to enter a new password for ‘guest’ and then confirm the password by entering it again. This process places the selected password into the .htpasswd file in encrypted form. Check it out. The password is encrypted to protect it from prying eyes. However if your password isn’t a good one, then someone may be able to grab a copy of the .htpasswd file and crack your password! If you want to know if your password is good or not see, Good Password.

Adding Users & Changing Passwords

To add new users follow the above procedure without using the -c option flag.
Example:

htpasswd /public_html/restricted/.htpasswd nobody

Again DO NOT USE the -c option flag.
To change a password (which should be done periodically) we again use htpasswd:
Example:

htpasswd /public_html/restricted/.htpasswd guest

You will again be prompted to enter the new passwords. htpasswd does not provide a way to remove users from your password file. We suggest two methods change their password or open the .htpasswd file and delete the line that their user name appears on.

Choosing Passwords
DO NOT USE your UNIX login password as your web htaccess password. Here is why, these passwords are sent over an HTTP connection as unencrypted text which makes them vulnerable to sniffing. Additionally HTTP send the unencrypted password with EVERY request, in contrast with protocols like telnet that only send the password unencrypted once (this is why I strongly suggest SSH). So again you have been warned, if your account gets hacked into you will lose data and if they use your account to do further damage to the network you could end up loosing account privileges. Key word privileges.

Modifying .htaccess
Now that the user name and password have been created and saved we need to activate them. Every directory that you created an .htpasswd file for needs to have a .htaccess file with the following entry:

AuthName "restricted stuff"
AuthType Basic
AuthUserFile /www/foo/.htpasswd

require valid-user

The first directive, AuthName, specifies a realm name for this protection. Once a user has entered a valid username and password, any other resources within the same realm name can be accessed with the same username and password.

  • The AuthType directive tells the server to use the Basic method for authentication (default).
  • AuthUserFile tells the server the location of the .htpasswd file created by htpasswd. A similar directive, AuthGroupFile, can be used to tell the server the location of a groups file (see below).
  • Require valid-user tells the server that any username/password pair in the .htpasswd file can be used to access this directory. However, it is possible to limit access to only certain users:
    require user guest nobody

This will only allow users guest and nobody access to the directory. Any other users would be denied access to the directory even though they may appear in the .htpasswd file.

Creating User Groups

Say we did not want to type out guest and nobody what could we do? We can create a group of users. This works well when there are a large number of users to manage. In this case we create a file that contains the group name and a list of the user names that belong to that group. Here’s and Example:

dumbgroup: guest nobody

The .htaccess file would look like this:

AuthUserFile /public_html/restricted/.htpasswd
AuthGroupFile /public_html/restricted/.htgroup
AuthName GroupAccess
AuthType Basic

require group dumbgroup

Note that all users in a group file MUST also appear in the .htpasswd file.

Combining Users and Groups
Your .htaccess file and include both users and groups. Here’s an example:

AuthUserFile /public_html/restricted/.htpasswd
AuthGroupFile /public_html/restricted/.htgroup
AuthName GroupAccess
AuthType Basic

require group dumbgroup
require user myself

The directory would then be accessible for ‘guest’, ‘nobody’, and ‘myself’.

Combining Different Types of Restriction

I think we have discussed the particulars enough so far. Here is an example:
Restrict access to only allow access to the Local Network additonally requiring the users ‘guest’ or ‘nobody’.

AuthUserFile /public_html/restricted/.htpasswd
AuthName "ByDomainAndUser"
AuthType Basic

order deny,allow
deny from all
allow from IP_address
require user guest nobody
require user nobody

Conversely, you can allow access to the Local Network, AND to users outside of the Local Network who have valid user name and password pair. This is accomplished by including the “satisfy any” directive in the .htaccess file. Example:

AuthType Basic
AuthUserFile  /www/foo/.htpasswd
AuthName "byDomainOrUser"

order deny,allow
deny from all
allow from 128.125.
require valid-user
satisfy any

Protecting Your .htaccess & .htpasswd Files

The use of .htaccess poses an interesting problem. In order to protect your files with .htaccess and .htpasswd these files must be readable by the Web Server. However, if the Web Server can read these files so can anyone! Even though the password file is encrypted DOES NOT mean that someone can not download the file and attempt to decrypt the passwords it contains! (This can be done in a number of ways, take my word for it.)

With Apache we protect against this situation by adding the require valid-user entry to the .htaccess file. You can not use UNIX permissions since that would conflict with the Web Server’s need to have read access to the files you wish to serve over the Internet.

FAQ’s:

I entered the restricted page by entering my password successfully. I proceeded to leave the page and surf the Internet. Later I returned to the restricted page and I was not prompted for a password, what’s wrong?!

Nothing is wrong! Once your user name and password are authenticated your ‘session’ is tied to your browser. If you were to terminate all browser sessions that you are running and then restart them, you would be prompted for a user name and password again. This is an important fact and you may want to make your users aware of this especially if users may access the restricted materials from ‘public’ machines.

Comments are closed.