Path // www.yourhtmlsource.comSite Management → PASSWORD PROTECTION

Password Protection

In general, all websites are freely viewable by anybody who wants to see them. Requiring a username and password to access various sensitive areas of your site allows you to restrict access to only a chosen few people who know the secret codes. In this tutorial I’ll present a method to secure a directory of documents by using a special Apache server configuration file.

Clock This page was last updated on 2012-08-21

Password protection through JavaScript

Before we get into this section, I present a minor caveat: using JavaScript to secure your website is an absolutely rubbish way to keep unwanted visitors out. If I encounter a site that tries to block access using JavaScript, it is a simple matter of temporarily disabling JavaScript in my browser to circumvent the dialog box. With no JavaScript, the link to the protected area of the site will work like any other normal link, and I will be able to roam free through the heretofore unseen depths of the site.

On top of this rather large chink in the armour, those pages will also be automatically indexed by search engines, leaving the private information accessible simply by searching for it.

So, given that any halfway competent infiltrator will easily be able to access a site secured only through JavaScript, I am not going to describe the method to do it, as there are significantly more secure ways to protect a section of your site that are much safer to use.

Using a .htaccess file

This special “.htaccess file”, which you may have encountered before if you’ve set up your own 404 error, is a configuration file for the Apache web server. It is just a text file with a special name that contains rules that your server will apply before it sends any files to a viewer of your site. These rules can change the URL of a page, create custom error messages, or in this case require a valid username and password to gain access to a certain area of the site.

These configuration files work on a directory basis, so if your site is at and you place the .htaccess file in the root directory (where your index.html homepage is), the entire site will be off-limits and all visitors will need a password to view anything. This is generally not what you want, and so you will create a .htaccess file within a certain directory.

When you set up authorisation for a certain directory, that directory, all of its files, and any directories within it are all protected by this one file. You can have multiple different .htaccess file in multiple directories in your site if necessary.

To create the file, open your text editor and save a blank file as “.htaccess” in the directory you want to protect, noting that the filename starts with a dot. Windows users may find that they are told they can’t start a filename with a dot. If you get this error, use your FTP program to create the .htaccess file on your server and edit it there instead.

Setting up Authorisation

Now that we have our all-important .htaccess file, we’ll need to add the authorisation rules to it. Add these lines to your file:

AuthName "Section name"
AuthType Basic
AuthUserFile /.htpasswd
Require valid-user

Change the “Section name” to whatever the secure section of your website is called. This value will be placed in the dialog box when a user is asked for their details, so try to make it descriptive so that they know what they’re being asked for. The dialog looks like this in Firefox:

Firefox .htaccess authentication dialog box

If you save that file now and try to access this part of your website, you should be presented with a dialog box in your browser asking you for your username and password. Of course, there is no right answer yet because we haven’t set up any users. If you press Cancel in the dialog you will be given the standard “401 Authorization Required” error response code. This is what everyone will see if they log in incorrectly.

The .htpasswd file

To add valid users to our authentication scheme, we use a second file called a .htpasswd file. This file will hold a list of usernames and passwords. Because it contains potentially sensitive information, you should store it in a place that’s impossible to access from the web. This means putting it somewhere else on the server outside of your “web” or “www” directory where your website files are stored. Your hosting company will be able to help you place this file securely so that no ne’er-do-wells can access it.

Once you have secured this file, change the line in .htaccess that points to it. It’ll then look something like this:

AuthUserFile /usr/home/ross/.htpasswd

Finally, we just need to start adding valid users to this file. For added security, the passwords of your users aren’t stored in plain text in the .htpasswd file — they’re encrypted so that they can’t be read by a user snooping around the server. To add a user called “rustyleroo” with the password “flummox45”, we would add this line to the file:


As you can see, the password has been obfuscated into a strange form of gobbledegook. I derived this value (technically called a “hash”) by running the original password through an encryption program. There are lots of these available online (this one for example). You can add new users by adding new lines to this file, all in the form username:encryptedpassword.

Accessing the protected section

Now when you reload a file behind the authorisation wall, you enter a username and password into the dialog box. The server will encrypt this password again, and compare it to the encrypted version stored in the file to see if they match. If they do, you will be allowed to view the rest of the protected files as normal.

You can send the username and password to people in this format:

Clicking a link like that will log you in as the user at the start of the URL. Of course, you need to make sure that only the intended person gets their hands on this information.

Finally, to remove any password restrictions on your files, just delete the .htaccess file. For the final cherry on the cake, you can follow the steps in the 404 error tutorial, but instead set up a custom 401 error, so that users who log in incorrectly get a nicely-formatted error message.