- page 22

HTTPS is necessary only when traffic interception is strongly undesirable or likely. The use of this protocol is especially recommended when a user's login and password are sent unencrypted every time the user accesses a document. An example of such a situation is HTTP Basic authentication.

There are a few other cases, in which it is necessary to use authentication through HTTPS with the users' private keys and asymmetric encryption algorithms. This authentication system is the most effective of the systems described earlier. However, it is the most difficult to implement.

As a more advanced variant of authentication system, private keys can be stored on smart cards and other specialized devices designed for this purpose. A correctly implemented authentication system based on public or private keys would provide maximum protection against traffic interception and unauthorized reading of files on the server. In some cases, even unlimited access to the client won't allow an attacker to obtain the information necessary for successful authentication and authorization.

Methods for Strengthening Protection

Sometimes, even a well-designed protection can be improved and the likeliness of its breakage can be lowered .

Limitation by an IP Address

When the users' IP addresses are known beforehand, you can limit access by an IP address in addition to using other methods. A list of valid IP addresses can be either static (built into the system during its creation) or dynamic (updated by an authorized administrator).

A drawback of this system is obvious: It cannot be applied when users' IP addresses can be random and don't fall within a certain range.

As a variation of this system, when IP addresses of the users aren't known beforehand, the following approach can be used: During primary authentication, when a user enters his or her login and password and the authentication is successful, the user gets a session ID with a limited lifetime. In addition, the user 's IP address is remembered . A subsequent authentication using this session ID will be allowed only from this IP address.

This approach will securely protect the system against session ID interception; however, you should be aware of the following:

• This system won't protect against login or password interception.

• This system will work only if the user's IP address doesn't change during the session. That is, the duration of the session won't be long for dial-up users, and it will be impossible to save the session for a few days.

In addition, during primary authentication you can store the browser name and the contents of some other fields in the HTTP header that can be different in different browsers. As a result, the session will be valid only for a particular browser version. Because the session ID is usually stored in a cookie, this approach is based on a reasonable assumption that the user won't change the browser during the session. Even if he or she does so, it will suffice for him or her to log into the system anew.

However, you should be aware that this is a policy of confusing. An attacker can easily edit appropriate headers in an HTTP request so that they are identical to the headers sent by the browser of a valid user.