Digital Elephant Productions
Logging in
A common requirement for a website is that the server have some way of identifying the client, either to personalize the site content, or to restrict access to parts of the site. A number of common schemes are in use, with various bells and whistles attached.
The least safe scheme is for the browser to send the username and password in a login request to the server. While the data are in transit (over the Internet), any eavesdropper may record the information, and later use it to gain equivalent access to the website. This style of login is really only appropriate for situations where all potential eavesdroppers are known to be friendly (eg, when all users are required to be connected to a local network, and they all are trusted colleagues).
Attempts have been made to use a challenge/response scheme to deny an eavesdropper the opportunity to steal login data. One such scheme (modeled on the IMAP authorization described in RFC 2195) begins with the server, which sends a key with a short time-to-live to the browser. The browser uses this key to encrypt the password supplied by the user (and perhaps some other fields as well, to increase the difficulty of cracking the encryption), and then sends the encrypted string back along with the username to the server. The server is no better at cracking the encryption than an attacker, but it does have an advantage: it knows the key, and it knows when it was sent. Therefore, the server can duplicate the encryption that the browser has performed, and compare the result to the encrypted string that the browser supplied, and do it much sooner than an attacker could. If the encrypted strings match and not too much time has elapsed, then the original password must be correct, and the server is safe in granting access.
The short lifetime of the key is essential: it puts a limit on how long an eavesdropper has to crack the encryption and attempt an unauthorized login. If the server receives an encrypted string whose key is too old, it may suspect an attack by an eavesdropper, and deny the request unconditionally. (The other possibility is that the client seeking access fell asleep between the time the login page appeared and when he actually tried to log in.)
This "fairly safe" approach solves one problem, and produces another: since the browser may never send the password to the server, it is not possible for the client to change his password directly. Doing so would re-open the security hole that we have worked so hard to close. One way out of this puts an administrative burden on a system administrator, to field requests to change passwords. The other is to provide a secure HTTPS channel from browser to server, over which the password-change transaction takes place. With a little bit of protocol design, it is possible for a single HTTPS server (with only its own certificate) to serve as a password-receipt server for many hosted websites on the same server.
The most secure scheme for providing authorization is to use HTTPS as the transport over which login (and password change) occurs. In this case, the secure communication channel is established before any data are exchanged between server and client, which eliminates the threat from eavesdroppers. This approach permits exchange of user/password data without further encryption, and so allows us to create a safe way for a user to change his password. The cost is more computing both at the server and at the client, to support the HTTPS protocol, and a separate IP address and X.509 certificate for each website hosted on a server.
Once a user is authenticated, the server must keep track of the "session", and make sure that each page request from the client for a session is authorized. A small amount of server code at the head of each page script can take care of this access check.