Password protection and user authentication for http servers like the open source Apache and Microsoft iis comes in two standard flavors. These password protocols are defined in rfc 2617 as Basic Authentication and Digest Authentication.Password protection and user authentication for http servers like the open source Apache and Microsoft iis comes in two standard flavors. These password protocols are defined in rfc 2617 as Basic Authentication and Digest Authentication. You might also see them called security protocols or authentication protocols. These mechanisms are expected to be supported universally in all standards-compliant http clients and http servers.

There are also any number of user identification and user login schemes based on asp or php scripts parsing URL parameters, login forms data and cookies which have been implemented by individual sites as custom login methods. As these are interpreted scripts unlike the compiled code used for an Apache module or iis isapi filter, it can be expected that throughput on the server will suffer under high loads.

While the term user login is often used on html pages and in casual references, it is not an accurate description of the actual processes at work. A login process suggests that once it is performed, a user has some special status. Since the http protocol is stateless, this cannot be the case. A more accurate term is authentication based access control. The http protocol specifies that it is permissible for the server to return a 401 – authorization required status code in response to a client request.

The proper response for the client browser to such a challenge is to prompt the users for their account names and user passwords. The browser will then repeat the request with an additional http authorization header that represents the user account and password. On subsequent authorization challenges within the same domain and session, the browser will simply repeat the request with an authorization header using the same credentials that the user supplied the first time. While this client-side behavior gives the appearance to a user of a logged in state, it is very important to understand that in fact every request has access control applied to it individually.

Basic authentication is the oldest form of password protection. It is well supported by most modern Web servers and client browsers. Although widely supported, it is, as the name says, pretty basic. The problem with this form of user authentication is that it is insecure. The user name and password are encoded using base-64 encoding before being sent by the browser to the server. Notice that we said encoded and not encrypted. Base-64 encoding was originally designed as a means of data transmission, not as a security protocol. Decoding base-64 data transmissions is a completely trivial task.

Digest authentication was introduced as a replacement for basic authentication in rfc 2617 and its predecessors as a more secure alternative for http/1.1 user authentication and password protection. The advantage of digest authentication is that the user password is not sent over the network. Instead, a md5 cryptographic hash of the user name, account password and certain other specified elements is calculated by the client browser and sent to the server as proof that the user knows the account password. The server then calculates an independent copy of the secure hash and compares it with the received hash as the basis of granting access.

Although subject to certain esoteric attacks, the digest authentication form of password protection is more secure than basic authentication by several orders of magnitude. The only latent disadvantage is a small increase in server load. If secure password storage is used, there is also the fact that forgotten passwords cannot be retrieved.

Rfc 2616 which defines http/1.1 mandates that both clients and servers must support digest authentication to be compliant. Although the standard has existed for a number of years, full support for the standard in this area remains somewhat imperfect in the area of interoperability. Currently, digest authentication compatibility seems to be divided into two distinct camps. It has been observed that a number of browsers such as Mozilla, Opera and Amaya successfully operate with Apache servers but not iis servers. On the other hand, Internet Explorer (IE) is known to be fully compatible with iis servers but not Apache servers.

As the algorithm for digest authentication is somewhat complex, some observers believe that the root of the problem lies in the varying interpretations of the standard by software designers. In some instances this arises from inconsistencies that are found in the standards documents themselves.

Given that there is no control over client browser upgrades except in internal networks, the onus on solving this problem lies with server software suppliers. It is immaterial that a client browser is deemed to be non-compliant. Being software, the purported non-compliance is repeatable and reproducible behavior. Thus, it can be accommodated in the server software with complete certainty.

The consequence of the current lack of full interoperability between popular browsers and Web servers with respect to digest password authentication is that most public sites are using basic authentication. This least common denominator approach to implementing access control has been forced on operators of public sites until such time as full interoperability can be achieved under digest authentication.

Wanderware.com researched these interoperability problems and designed their password protection software to overcome these shortcomings. The software also offers numerous security, performance and scalability enhancements which cannot be found elsewhere.

The amount of information that can be found on this topic can be overwhelming. We suggest that you tailor your search by using the following terms in various combinations:

· user authentication

· basic authentication

· digest authentication

· isapi authentication filter

· iis password protection

· apache password protection

· http authentication

· password security

· password protocol

· authentication protocol

· digest interoperability

· password algorithms

· htaccess

· active directory

· mod_auth_digest

· mod_auth_db

Bob can be contacted by email through his Web site at http://coldlink.com/.

Password protection and user authentication for http servers like the open source Apache and Microsoft iis comes in two standard flavors. These password protocols are defined in rfc 2617 as Basic Authentication and Digest Authentication.Password protection and user authentication for http servers like the open source Apache and Microsoft iis comes in two standard flavors. These password protocols are defined in rfc 2617 as Basic Authentication and Digest Authentication. You might also see them called security protocols or authentication protocols. These mechanisms are expected to be supported universally in all standards-compliant http clients and http servers.

There are also any number of user identification and user login schemes based on asp or php scripts parsing URL parameters, login forms data and cookies which have been implemented by individual sites as custom login methods. As these are interpreted scripts unlike the compiled code used for an Apache module or iis isapi filter, it can be expected that throughput on the server will suffer under high loads.

While the term user login is often used on html pages and in casual references, it is not an accurate description of the actual processes at work. A login process suggests that once it is performed, a user has some special status. Since the http protocol is stateless, this cannot be the case. A more accurate term is authentication based access control. The http protocol specifies that it is permissible for the server to return a 401 – authorization required status code in response to a client request.

The proper response for the client browser to such a challenge is to prompt the users for their account names and user passwords. The browser will then repeat the request with an additional http authorization header that represents the user account and password. On subsequent authorization challenges within the same domain and session, the browser will simply repeat the request with an authorization header using the same credentials that the user supplied the first time. While this client-side behavior gives the appearance to a user of a logged in state, it is very important to understand that in fact every request has access control applied to it individually.

(more…)