Securing Your Web Pages with Apache Page 4

In almost all cases, a client that receives such a 'not authorised' response will realise that it didn't send any credentials, and will pop up a dialogue box for the end-user to complete. This box will display the name of the realm in which the document resides, and ask the user for a username and password. Once obtained, the client will make the same request again, only this time it will include the credentials. But as far as the end-user is aware, that first request was completely invisible and never happened.

If the client gets a 'not authorised' status in response to a request that included credentials, it typically responds a little differently: it will probably tell the user 'those credentials weren't accepted, want to try again?' It didn't say that the first time because it hadn't sent any.

In either case, if the end-user opts to not fill in the dialogue and presses 'cancel,' the client typically just displays the error page that the server sent along with the 'not authorised' status, and goes back to waiting for instructions.

Apache Security Processing Phases

The preceding sections have been subtly leading up to this topic. Apache handles all requests by running them through phases. Each Apache module has an opportunity to deal with the request during each of the phases, though most modules only do so for one or possibly two of them.

Apache has three processing phases relating to security checking. They occur in the following order, and are given the following names:

  1. access_checker -- This phase is where mandatory access checks are applied, such as mod_access' check for whether the client's IP address is allowed to access the document or not
  2. check_user_id -- This is the authentication phase, during which a DAC module such as mod_auth checks the user credentials to see if they're even in the database it's been told to use
  3. auth_checker -- This is the phase during which authorisation occurs; modules like mod_auth check to see if the user (who has already been authenticated) is allowed to access the document

Modules that impose discretionary access checks usually participate in the latter two phases.

Basic Authentication versus Digest Auth

How does the username and password get transmitted across the network? Well, in early 2000 the answer is: not very well. It's not that there are technical problems with the transmission; rather, the issues are more philosphical.

There are currently two main methods of passing credentials, called Basic authentication and Digest authentication. The Digest method is considerably more secure, but unfortunately less widely deployed -- so most authentication on the Web is done using the less-secure Basic mechanism.

Basic authentication involves simply base64-encoding the username and password and transmitting the result to the server. This means that anyone who can intercept the transmission can determine the username and password. Of course, this is only useful if those values are valid and end up getting successfully authenticated. <grin> Digest authentication transmits the information in a manner that cannot be so easily decoded.

This article was originally published on Jun 29, 2000

Thanks for your registration, follow us on our social networks to keep up-to-date