PERSONAL WEBSITE
BENOIT CHENU

Authentication

It is very common to need to protect a part of a web site, which is an administration section or simply a private space. Many authentication solutions by login / password are given to us.

1.1. Authentication by form

The principle of authentication by form is simple:

• The client emit a request on a page needing an authentication
• The server sends back a html form
• The user returns form data to the server
• The server validates the data

When navigating on the private space, it must be determine if the user is already logged on. The most common techniques are the use of cookies and sessions. Reminder:

• A cookie is a client's generated file. This file contains all variables that the server needs to put in. On each transaction, these variables are sent to the server.
• A session is a server generated file containing roughly the same thing. This file is identified by a 'session id'. A cookie is sent to the client contenting only this id. For each transaction, only the session id is sent to the server.

In our case, it is preferable to identify the user with sessions in term of security (only the id forwards on the network) and practice (stocking of variables often used).

The advantage of the authentication by form resides in its administration facility: the list of authorized users can be stocked in a database, LDAP directory or in a file. However, it is important to note that it does not permit to protect html files, images and all documents accessible directly by URL.

The risks of using sessions at this stage are at two levels:

• During authentication, the user's password is sent in clear.
• During transactions, the session id (circulating in clear too) can be stolen by ill-disposed person.

These problems can be solved by using HTTPS protocols, explained in the next chapter.

1.2. Securisation of directories by htaccess

Concretely, an htaccess is an http server configuration file. It permits, among other things, to limit the rights of access to a site directory. This is useful to reserve an administration zone or to offer a member space.

It is useful to know that htaccess can be written directly in the Apache configuration file. All that is necessary is to put directives in a <Directory> with directory path to protect or a <Location> with the URL.

<Directory /usr/www/administrateur>
	...
</Directory>

Or :

<Location / >
	...
</ Location>

There are two authentication methods described in RFC 2617 of http protocol: basic and digest

1.2.1. Basic mode

The basic mechanism is usually used because of its compatibility and simplicity when installing.

1.2.1.1. Principle

• The client emits a request on a protected page.
• The server answers with a 401 error (Unauthorized Access) and the authentication type. The request header is as follows:

HTTP/1.1 401 Authorization Required
WWW-Authenticate: Basic realm="private Access"

• The browser treats this request and shows a window inviting to seize its accreditations.

Once seized, this information is sent to the server. The browser reiterates the preceding request with authorization header. The username and password are concatenated (separated by « : ») and encoded in base64. For example, for a login / password user:password, the request is as follow:

GET / HTTP/1.0
Authorization: Basic dXNlcjpwYXNzd29yZA==

Accreditations are then saved, thus avoiding re-seizing them for each request.

This method is very sensitive to any traffic listening because information is not crypted and sent in each request. Just like form authentication, a SSL transport solution is considerable.

1.2.1.2. Syntax

AuthType Basic
AuthName "private access"
AuthUserFile /etc/httpd/conf/htpasswd
Require valid-user

• AuthType: defines the authentication type
• AuthName: message describing the section on the window
• AuthUserFile: users file path
• Require: directive determining authorized users. 'valid-users' allow logging to all users defined in the specified file.

Users file can be generated with the htpasswd utility.

1.2.2. Digest Mode

In the opposite of basic mode, this method offers a confidentiality service for accreditations, introducing a mechanism against replay and protecting the client against a spiteful server.

The mechanism is known under 'challenge/response' name: the server sends a challenge to the client, this one answers by a derived value of this challenge and by a secret that he chares with the server. The server makes sure that the client has the secret by calculating the response.

1.2.2.1. Principle

• The client emits a request on a protected page.
• The server answers with the same error code 401, a challenge 'nonce' and a hash algorithm identifier. We obtain a request as follow:

HTTP/1.1 401 Authorization Required
WWW-Authenticate: Digest realm="private Access",
nonce="vR54Tk==a965d986fa716e4d4592943b5762c73958f0328C",
algorithm=MD5, domain="/", qop="auth"

For each request, the client will have to calculate his response with these parameters. Because the challenge is not renewed each time, this limits the non-replay.

• The browser displays a window inviting to seize his accreditations. Once the information is seized, the client calculates his response. The calculation will not be detailed (it is available in RFC 2617). The response is a hash series of login, realm, password, cnonce (value choose by the client) and URL.

It is useful to know that the server has no knowledge of the password. In the users file, the login is saved, realm and a hash of 'login:realm:password'.

We obtain a response like this:

GET / HTTP/1.1
Authorization: Digest username="user", realm="private Access",
nonce="vR54Tk==a965d986fa716e4d4592943b5762c73958f0328c",
uri="/", algorithm=MD5, response="411d4c35a806746ab353c67ab4e9cf5a",
qop=auth, nc=00000001, cnonce="af08d67c532a3a01"

• The server answers with an Authentication-Info header:

HTTP/1.1 200 OK
Authentication-Info: rspauth="1d4d5a9d920fb22197471146c613e767",
cnonce="be09d67c532a3a02", nc=00000001, qop=auth

rspauth allows a mutual authentication, proving that the server knows indeed the client's password.

It is important to note that the non-replay is placed at the level of 'http session' (time during which the nonce is usable) and not at the level of http request. The time to live is defined in the configuration of the module mod_auth_digest with the parameter AuthDigestNonceLifeTime. Beyond this duration, the nonce will be renewed and the client will have to authenticate once more. We can thus realize that this module offers a real confidentiality system of accreditations and not truly a non-replay service.

Besides its many advantages, the Digest module is also known for its incompatibility in between Apache and Internet Explorer and so between IIS and all others browsers (except MSIE of course). This incompatibility is due to a bad interpretation of the RFC 2616 by Microsoft.

The problem is located at the calculation level of the response. As we saw, the client generates his response with the URI (among other things). The RFC defines that the QUERY_STRING (string located after '?') must be taken in account, but MSIE and IIS don't do it. Consequently when the server re-calculates the client response, this one does not match and the client is rejected with a 404 Bad Request error.

The solution to this problem is not to pass variables by GET but in the request: by POST.

1.2.2.2. Syntax

AuthType Digest
AuthName private Access
AuthDigestFile /etc/httpd/conf/htpasswd
Require valid-user

The users file can be generated with the htdigest tool.

Caution: in Digest, AuthName allows to identify the user in addition of his login checking. This allows gathering users in a section. It must match with the realm in the users file.