When HTTP authentication is required by a web server, then this authentication takes place for every single request. So for every single request that the web server receives it must decode the message, find the username and passwords then verify these with the ones in it’s user database (if this is the method being used). Naturally this takes a lot of effort and the most obvious result is that of speed, the connection will slow down to allow all this processing.
There are other methods to circumvent this difficulty with HTTP and the most popular is probably the ‘cookie’. What will likely happen is that if a request is received with no authentication credentials and without a cookie then the user receives a 401 request – (401 – is authentication required). The client browser functioning in normal mode, and not the privacy enabled sessions like incognito in Chrome will remember which servers require authentication and which won’t. This enables the client to send the authentication credentials automatically, thereby saving the inconvenience of another 401 response.
Of course there are other authentication methods, for example the securID cards have passwords that change each time, in this case there is no alternative but for the user to enter his password on each request. One of the most common solutions for preventing this is by passing a cookie after a successful authentication request. Any subsequent requests the cookie can be forwarded, most servers will accept this file as a valid authentication credentials.
The information must be secure in the cookie, typically encoded and then verified with an MD5 signature. This stops the cookie being altered or modified in transit, the other information that would be normally included in the file would be
- User ID
- IP Address of Origin
- Cookie Expiration Time
- Cookie Signature/Fingerprint
Part of this data will be encrypted and other parts like the expiration and IP address will usually be in clear. This clear text data and the MD5 portion of the file can be used to verify the cookie’s validity along with a random string that is generated and passed when the cookie is originally created.
This transparent pass through is important in many applications, a well configured proxy must be able to handle these requests easily. Unfortunately normal cookies cause issues for use with proxies as they are designed to be exchanged between client and server end points. Take for instance this instance where you use a proxy to watch UK TV abroad as in this video –
Using such services might mean that your IP address changes during the connection, which will effectively invalidate the cookie. This means that either the session is disconnected or re-authentication must occur. If the proxy can handle these connections properly then the cookie will remain valid – it can be quite difficult to configure though.
