Weaknesses of HTTP authentication
Date : April 07, 2010
It appears that among the different HTTP session management techniques, the session management via cookies is the most widely used.
If the low security level of the "HTTP Basic" authentication explains its limited use, the explanation is less obvious for the "HTTP Digest" authentication.
It is possible that application developers and administrators are reluctant to use this method more because of a lack of flexibility of the user interfaces rather than because of a weakness in the security protocol.
Authentication based on application form
Over the years, web developers have published various methods that attempt to provide customizable HTML forms allowing to use the HTTP Basic and HTTP Digest Authentication.
An interesting approach is the use of AJAX features to take control of the authentication process.
The identifiers are entered via an HTML page, and then they are used via the "open" method of an XMLHttpRequest object.
If the connection succeeds, the AJAX request receives in return an HTTP 200 response and the browser displays a home page.
If the connection fails, the script displays a custom error message.
This approach is unfortunately not fully operational without a little adjustment.
Indeed, when they receive a 401 error code (authentication failure) from the server, even in response to an AJAX request, most browsers display their own form to ask users their credential. This behavior means that the authentication process escape to the web application control after a user fails on his first authentication attempt.
To circumvent this problem, developers can customize the "/ private / login-check.cgi" script so that it returns another error code that is ignored by the browser and could allow further processing in JavaScript.
This circumvention of the HTTP specification may seem artificial, but the W3C is working on a project to standardize the XMLHttpRequest class. This would improve this aspect related to an authentication failure.
Improving the process of disconnecting
The lack of application running at disconnection seems to be a greater limitation of the use of HTTP authentication with browsers.
A number of JavaScript applications specific to different browsers have been developed to handle this issue, but these approaches are heterogeneous. It would be interesting to add the HTTP error code or a field to handle disconnections.
Immaturity implementations
Although the lack of flexibility of connections and disconnections is a major obstacle to the adoption of "HTTP Digest" authentication, we should also note the immaturity of several browser vendors and web servers that actually provide an incomplete implementation of this authentication protocol.
Low security level user interfaces for HTTP authentication
The user interfaces of the major Web browsers have in fact several security weaknesses. Indeed some browsers:
Conclusion
HTTP being a stateless protocol, the solutions used to manage sessions over HTTP are based on methods that were added to the initial protocol specification.
Among the various methods, the most used is the one that uses cookies.
However, the HTTP authentication methods used in addition with SSL offer a correct security level which could be improved by some modifications of the protocol (HTTP disconnection management) and web browsers (more flexibility and better security of GUI used during the authentication).
For more information :
If the low security level of the "HTTP Basic" authentication explains its limited use, the explanation is less obvious for the "HTTP Digest" authentication.
It is possible that application developers and administrators are reluctant to use this method more because of a lack of flexibility of the user interfaces rather than because of a weakness in the security protocol.
Authentication based on application form
Over the years, web developers have published various methods that attempt to provide customizable HTML forms allowing to use the HTTP Basic and HTTP Digest Authentication.
An interesting approach is the use of AJAX features to take control of the authentication process.
The identifiers are entered via an HTML page, and then they are used via the "open" method of an XMLHttpRequest object.
If the connection succeeds, the AJAX request receives in return an HTTP 200 response and the browser displays a home page.
If the connection fails, the script displays a custom error message.
This approach is unfortunately not fully operational without a little adjustment.
Indeed, when they receive a 401 error code (authentication failure) from the server, even in response to an AJAX request, most browsers display their own form to ask users their credential. This behavior means that the authentication process escape to the web application control after a user fails on his first authentication attempt.
To circumvent this problem, developers can customize the "/ private / login-check.cgi" script so that it returns another error code that is ignored by the browser and could allow further processing in JavaScript.
This circumvention of the HTTP specification may seem artificial, but the W3C is working on a project to standardize the XMLHttpRequest class. This would improve this aspect related to an authentication failure.
Improving the process of disconnecting
The lack of application running at disconnection seems to be a greater limitation of the use of HTTP authentication with browsers.
A number of JavaScript applications specific to different browsers have been developed to handle this issue, but these approaches are heterogeneous. It would be interesting to add the HTTP error code or a field to handle disconnections.
Immaturity implementations
Although the lack of flexibility of connections and disconnections is a major obstacle to the adoption of "HTTP Digest" authentication, we should also note the immaturity of several browser vendors and web servers that actually provide an incomplete implementation of this authentication protocol.
Low security level user interfaces for HTTP authentication
The user interfaces of the major Web browsers have in fact several security weaknesses. Indeed some browsers:
- do not specify the type of authentication they use ("Basic" or "Digest"), this can fool users about the security level of their HTTP sessions,
- use a password manager that does not differentiate the several types of authentication and uses cached credentials even when they have been saved using another authentication type.
- do not differentiate clearly the domain name and the parameter "realm", used by HTTP authentication.
Conclusion
HTTP being a stateless protocol, the solutions used to manage sessions over HTTP are based on methods that were added to the initial protocol specification.
Among the various methods, the most used is the one that uses cookies.
However, the HTTP authentication methods used in addition with SSL offer a correct security level which could be improved by some modifications of the protocol (HTTP disconnection management) and web browsers (more flexibility and better security of GUI used during the authentication).
For more information :
- Study of "Virtuals Security Research": http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
- RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1) : http://www.ietf.org/rfc/rfc2616.txt
- RFC2617 (HTTP Authentication: Basic and Digest Access Authentication) : http://www.ietf.org/rfc/rfc2617.txt
- RFC2965 (HTTP State Management Mechanism) : http://www.ietf.org/rfc/rfc2965.txt
