A Guide to Web Authentication Alternatives

Table of Contents

1. Introduction

2. Authentication Options Supported by HTTP Servers and Browsers

2.1. Basic Authentication

2.1.1. How Basic Authentication Works

2.1.2. Advantages and Disadvantages of Basic Authentication

2.2. Digest Authentication

2.2.1. How Digest Authentication Works

2.2.2. Advantages and Disadvantages of Digest Authentication

2.2.3. Why Digest Authentication Isn't Used

3. Do-It-Yourself Authentication Options

3.1. Where to Do Authentication

3.1.1. Authentication in HTTP Server Daemon

3.1.2. Authentication in CGI Programs

3.2. Collecting and Checking Login Information

3.2.1. Designing the Login Form

3.2.2. Checking the Login

3.2.3. Reload-Proofing the Next Page

3.3. Preserving Login Information

3.3.1. Methods for Passing Authentication Information

3.3.1.1. Passing information through link parameters

3.3.1.2. Passing information through cookies

3.3.2. Methods for Encoding Authentication Information

3.3.2.1. Using encrypted user IDs

3.3.2.2. Using session IDs

4. Conclusions

5. Acknowledgements

I originally did a lot of thinking and studying on some of these methods in hopes of developing a better authentication system for my web conferencing system, Backtalk. This report summarizes my conclusions about the strengths and weaknesses of various methods that I have considered. I've since built many web authentication systems for many customers, so I've continued to update this with new ideas and concerns.

I will discuss the two standard authentication systems which are described in the HTTP protocol documents: "basic authentication" which is supported by most browsers and HTTP servers, and "digest authentication" which isn't. I will then discuss various "do-it-yourself" alternatives to basic authentication, focusing on the three basic phases to the web authentication process:

1. Logging in: The user must be prompted for a login and password. Some program on the server must check these against a database to confirm that they are valid.

2. User Tracking: Normally there is no persistent connection between a user's browser and and your web server. If the web-site consists of more than one page, and if you don't want the user to have to log in again for each new page he looks at, we need some way to preserve the login information from page to page.

3. Logging Off: If we have a way to remember that a user is logged on, we also need a way to destroy that information when the user logs off.

Several commonly used server-side web development packages (such as Microsoft's Active Server Pages, Allaire's Cold Fusion, or Apache's Tomcat server) have authentication systems built in. I won't describe how to use those here. Internally, they all work in much the same way as the "do-it-yourself" methods described here, except that they are mostly done for you. Though this document does not describe the pre-fabricated authentication packages available, it is a pretty thorough discussion of the issues involved, and thus potentially educational for those interested in evaluating pre-fab packages.

While most of this report applies equally to servers on all platforms, some of the details are specific to Unix systems. There are probably many issues relevant to security on NT systems that I personally don't know much about. Security issues on Unix systems are generally better understood due to wide availability of information about their internal operation.

Finally, the advice and opinions expressed here are my own. No guarantees of completeness or accuracy are intended. If you disagree, let me know, but in the final analysis you must use your own judgment in designing your authentication systems.

Next Sections:
2. Authentication Options Supported by HTTP Servers and Browsers
3. Do-It-Yourself Authentication Options