'Unsetting' Basic Authentication

The Corinthian

I’ve a log in script that uses the basic authentication dialog rather than a HTML form to take in username / password input. After this, I switch over to a sessions and it’s pretty standard from then on.

The problem I seem to be having is that I cannot seem to ‘unset’ the basic authentication data - which leaves me in a situation whereby the username / password is being passed with every request (not good). I’m using PHP, although the problem seems to be client rather than server side as it is the browser that persists on sending it.

Any suggestions?

pH

If you're using HTTP authentication then this does indeed happen:

When a particular resource has been protected using basic authentication, Apache sends a 401 Authentication Required header with the response to the request, in order to notify the client that user credentials must be supplied in order for the resource to be returned as requested.

Upon receiving a 401 response header, the client's browser, if it supports basic authentication, will ask the user to supply a username and password to be sent to the server. If you are using a graphical browser, such as Netscape or Internet Explorer, what you will see is a box which pops up and gives you a place to type in your username and password, to be sent back to the server. If the username is in the approved list, and if the password supplied is correct, the resource will be returned to the client.

Because the HTTP protocol is stateless, each request will be treated in the same way, even though they are from the same client. That is, every resource which is requested from the server will have to supply authentication credentials over again in order to receive the resource.
http://httpd.apache.org/docs/1.3/howto/auth.html

The obvious way around this to make all the content pages (after the login) unauthenticated, and rely on a PHP session having been created (from the login page after successful authentication)

The Corinthian

pH wrote:

Upon receiving a 401 response header, the client's browser, if it supports basic authentication, will ask the user to supply a username and password to be sent to the server.

Unfortunately this does not actually happen, browsers just ignore the 401 header and will pop up the dialog box only on a 'WWW-Authenticate' header.

The obvious way around this to make all the content pages (after the login) unauthenticated, and rely on a PHP session having been created (from the login page after successful authentication)

I've already done this and it is not a problem. The problem is the browser persists in sending the username / password in the request headers - which for obvious security reasons, I would like to unset.

markpb

I'm not sure if it solves your problem but you could take a look at this link which deals with Basic Authentication.

pH

Looks like you're hitting RFC2617

A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the Proxy-Authorization header field without receiving another challenge from the proxy server. See section 4 for security considerations associated with Basic authentication.

Most browsers it seems do implement this pre-emptive sending of the auth headers. As you say there may be a setting in firefox or IE to turn this behaviour off.

The RFC seems to imply that pre-emptive auth-headers are only send to paths deeper than the path that actually competed the challenge, so a restructure might turn this behaviour off.