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. Digest authentication transmits
the information in a manner that cannot be so easily decoded.