|
|
Password Protection
is a way of restricting access on your domain. While
it is available, there are quite a few steps that must be taken as listed
below. If you are interested in protecting any part of your site, please
contact Technical Support for assitance.
.htaccess
Instructions
| Creating
a User Database |
A list of users and
passwords needs to be created in a file. For security reasons,
this file should not be under the document root. The examples
here will assume you want to use a file call users in your server
root at /domain/<username>
The file will consist
of a list of usernames and a password for each. The format is
similar to the standard Unix password file, with the username
and password being separated by a colon. However you cannot just
type in the usernames and passwords because the passwords are
stored in an encrypted format. The program htpasswd is used to
add create a user file and to add or modify users.
htpasswd is a C
program that is supplied on the server.
|
| Using
htpasswd |
To create a new user
file and add the username "jessica" with the password "4rabbit2"
to the file /domain/<username>/users:
htpasswd -c /domain/<username>/users
jessica
The path to htpasswd
on our server is /var/www/bin
On our server, for example, use:
/var/www/bin/htpasswd -c /domain/<username>/users jessica
The -c argument
tells htpasswd to create new users file. When you run this command,
you will be prompted to enter a password for jessica, and confirm
it by entering it again. Other users can be added to the existing
file in the same way, except that the -c argument is not needed.
The same command can also be used to modify the password of an
existing user.
After adding a few
users, the /domain/<username>/users file might look like
this:
jessica:WrU808BHQai36
roger:iABCQFQs40E8M
art:FAdHN3W753sSU
The first field
is the username, and the second field is the encrypted password.
|
Configuring
the Server
|
|
To get the server
to use the usernames and passwords in this file, you need to configure
a realm. This is a section of your site that is to be restricted
to some or all of the users listed in this file. This is typically
done on a per-directory basis, with a directory (and all its subdirectories)
being protected (Apache 1.2. will let you protect individual files).
The directives to create the protected area can be placed in a
.htaccess file in the directory concerned, or in a
section in the access.conf file.
To restrict a directory
to any user listed in the users file just created, you should
create a .htaccess file containing:
AuthName "restricted
stuff"
AuthType Basic
AuthUserFile /domain/<username>/users
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. This can be used to create two areas which share
the same username and password.
The AuthType directive
tells the server what protocol is to be used for authentication.
At the moment, Basic is the only method available. However a new
method, Digest, is about to be standardised, and once browsers
start to implement it, digest authentication will provide more
security than the basic authentication.
AuthUserFile tells
the server the location of the user file created by htpasswd.
A similar directive, AuthGroupFile, can be used to tell the server
the location of a groups file (see below).
These four directives
have between them tell the server where to find the usernames
and passwords and what authentication protocol to use. The server
now knows that this resource is restricted to valid users. The
final stage is to tell the server which usernames from the file
are valid for particular access methods. This is done with the
require directive. In this example, the argument valid-user tells
the server that any username in the users file can be used. But
it could be configured to allow only certain users in:
require user jessica
roger
would only allow
users jessica and roger access (after they entered a correct password).
If user art (or any other user) tried to access this directory
- even with the correct password - they would be denied. This
is useful to restrict different areas of your server to different
people with the same users file. If a user is allowed to access
the different areas, they only have to remember a single password.
Note that if the realm name differs in the different areas, the
user will have to re-enter their password.
|
Using
Groups
|
|
If you want to allow
only selected users from the users file in to a particular area,
you can list all the allowed usernames on the require line. However
this means you are building username information into your .htaccess
files, and might not been convenient if there are a lot of users,
and . Fortunately there is a way round this, using a group file.
This operates in a similar way to standard Unix groups: any particular
user can be a member of any number of groups. You can then use
the require line to restrict users to one or more particular groups.
For example, you could create a group called staff containing
users who are allowed to access internal pages. To restrict access
to just users in the staff group, you would use
require group staff
Multiple groups
can be listed, and require user can also be given, in which case
any user in any of the listed groups, or any user listed explicitly,
can access the resource. For example
require group staff
admin
require user adminuser
which would allow
any user in group staff or group admin, or the user adminuser,
to access this resource after entering a valid password.
A group file consists
of lines giving a group name followed by a space-separated list
of users in that group. For example:
staff:jessica roger
admin:art adminuser
The AuthGroupFile
directive is used to tell the server the location of the group
file. Note that the maximum line length within the group file
in about 8000 characters (actually 8kB). If you have more users
in a group than will fit within that line length, you can have
more than one line with the same group name within the file.
Limiting Methods
Differently
In the example .htaccess
file above, the require directory is not given inside a
section. This is valid in Apache, and means it applies to all
request methods. In other servers and most example .htaccess files,
the require directive is given inside a section, such
as this:
require valid-user
In Apache it is
better to omit the and lines, to ensure that
the protection applies to all methods. However, this format can
be used to limit particular methods. For example, to limit just
the POST method, use
AuthName "restrict
posting"
AuthType Basic
AuthUserFile /domain/<username>/users
require group staff
Now only members
of the group staff will be allowed to POST. Other users (unauthenticated)
can use other methods, such as GET. This could be used to allow
a CGI program o be accessed by anyone, but only authorised uses
can POST information to it.
|
How
WWW Authentication Works
|
|
The method used in
HTTP for user authetication is quite simple. Since HTTP is a stateless
protocol - that is, the server does not remember any information
about a request once it has finished - the browser needs to resend
the username and password on each request. Here is how it works.
On the first access
to an authenticated resource, the server will return a 401 status
("Unauthorized") and include a WWW-Authenticate response header.
This will contain the authentication scheme to use (at the moment,
only Basic is allowed) and the realm name. The browser should
then ask the user to enter a username and password. It then requests
the same resource again, this time including a Authorization header
which contains the scheme name ("Basic") and the username and
password entered.
The server checks
the username and password, and if they are valid, returns the
page. If the password is not valid for that user, or the user
is not allowed access because they are not listed on a require
user line or in a suitable group, the server returns a 401 status
as before. The browser can then ask the user to retry their username
and password.
Assuming the username
and password was valid, the user might next request another resource
which is protected. In this case, the server would respond with
a 401 status, and the browser could send the request again with
the user and password details. However this would be slow, so
instead the browser sends the Authorization header on subsequent
requests. Note that the browser must ensure that it only sends
the username and password to further requests on the same server
(it would be insecure to send those details if the user moved
onto a different server).
The browser needs
to remember the username and password entered, so it can send
them with future requests from the same server. Note that this
can cause problems when testing authentication, since the browser
remembers the first username and password that works. It can be
difficult to force the browser to ask for a new username and password.
|
Security
and Digest Authentication
|
|
While authentication
does allow resources to be restricted to particular users, there
are potential security issues. Some of these are:
Care must be taken
to ensure that the resource is restricted against all methods.
Use of , for instance, leaves POST and other request
methods unprotected.
The username and password are stored in a plain text file. While
the password is encrypted, it is not completely safe against decryption,
so the file should not be accessible to other users on the system.
More importantly, it should not be placed under the document root
where users from other sites could access it.
The username and password is as secure as any username/password
system, in that end-users should not tells others their password,
or write it down, or make it easily guessable.
The Basic authentication scheme transmits passwords across the
Internet unencrypted, so they could be intercepted. The Digest
method, see below, is intended to address this issue.
The Digest Authentication
scheme will make the sending of passwords across the Internet
more secure. It effectively encrypts the password before it is
sent such that the server can decrypt it. It works exactly the
same as Basic authentication as far as the end-user and server
administrator is concerned. The use of Digest authentication will
depend on whether browser authors write it into their products.
Apache can already do Digest authentication, when compiled with
the mod_digest module (supplied with the Apache distribution).
|
|
Denying
Access
|
|
This function is
somewhat similar to the password protection. Using this, you can
deny access to certain IP or IPs. For example, if you don't want
somebody to be able to access your site, all you have to do is
place the following code into your .htaccess file:
<Limit
GET>
order allow,deny
deny from 192.76.80.65
deny from 128.23.45.
allow from all
</Limit>
This code will block
192.76.80.65 IP and all others that are starting with 128.23.45.
Everybody else will be able to access your site. You can block
as many visitors as you want, but be careful or you can eliminate
innocent visitors as well. Note: Only IP address are allowed.
No domains!
|
|
Changing
the default start page
|
| As you probably know
98% of all servers have index (index.html, index.htm, index.shtml,
etc.) as their default pages. This means that if you'll try to access
http://site.com/folder/, you will be automatically redirected to
http://site.com/folder/index.html or something similar. If for any
reason you want the default page to be, for example, page.html (meaning
that http://site.com/folder/ will redirect to http://site.com/folder/page.html),
you can do this by using .htaccess file. All you need to do is to
add the following line to your .htaccess file:
You can change page.html
to any page you wish. You can even specify a CGI file to be executed.
The possibilities are endless. One line is all you need.
|
|
