Timothy D. Morgan of Virtual Security Research (VSR) has written a paper proposing a system for web applications to authenticate users that offers significantly better security than the common practice of storing session IDs in cookies. Morgan's proposal is based on the existing (but seldom-used) HTTP Digest Access Authentication method, so it could be implemented with very little effort in existing web browsers and web servers. He argues that digest authentication's lack of popularity is primarily due to inflexible implementations that web developers find inconvenient compared to the simplicity of using cookies, and suggests some changes that could make it more appealing.
The paper, "Weaning the Web off of Session Cookies: Making Digest
Authentication Viable," is available
as a PDF from the VSR web site. Morgan begins by outlining the established
security problems with using cookies to store session IDs on the user's web
browser. In a typical scheme, a user authenticates to a web application
via a username/password combination entered through an HTML form, after
which a session key is sent back to the user's browser and stored in a
cookie, the value of which is either generated pseudorandomly or is some
value that is encrypted server-side.
Even if the communication channel uses SSL/TLS, however, there are
security problems with this approach. The pseudorandom number generator
may be predictable or the encryption algorithm insecure, allowing an
attacker to spoof the session. Worse, such session IDs can be exposed in
URLs, and captured in referrer logs, proxy logs, and browser histories. In
addition, many popular web application frameworks set a session cookie
before requiring login,
then subsequently "upgrade" the session to an authenticated
state after redirecting the user to a login page — but using the same
cookie. An attacker can hijack such a session simply by visiting the HTTP
site before the login takes place and recording the session ID.
Morgan then explains the basics of HTTP Digest Authentication, which was introduced with HTTP 1.1 in RFC 2069, and updated in RFC 2617. Digest authentication is an improvement over HTTP Basic Access Authentication, which simply encodes the username/password combination in base64 and transmits it to the server in plaintext.
Digest authentication is significantly more secure, because it computes a cryptographic hash based on the username, password, HTTP authentication realm, a server-provided nonce, the URI requested, the request method and (optionally) the request body. The RFC 2617 revision also includes a nonce count and a client nonce to further protect the integrity of the request.
The primary reason that digest authentication is not popular with web developers, Morgan says, is that it does not integrate into application and site design. All major web browsers implement HTTP basic and digest authentication in the same way, by launching a generic, modal pop-up window prompting the user for his or her username and password. The pop-up cannot be integrated into page design, nor customized, which makes it unappealing to developers. In addition to that, when using digest authentication there is no established method for the application to log the user out (which is a security risk of its own).
Finally, the current version of HTTP digest authentication specifies the MD5 hash algorithm, which is known to be vulnerable to preimage computation — although using the RFC 2617 mode makes such an attack impractical by incorporating the client-side nonce in its response.
The proposed improvements
Morgan suggests three methods to make digest authentication more accessible — and thus, useful — to web application developers.
The first is to use AJAX to take a username/password combination from an
HTML form and generate the HTTP digest authentication request, which
preserves the developer's ability to customize and control the login page.
Making this method work seamlessly, however, would require a change to the
way application respond if the username/password fails. Most web servers
send a 401 error
code, which causes today's browsers to automatically open a pop-up window; thus negating the work to integrate the authentication into the page. If the server returned a different error code, however, that problem could be avoided.
More difficult is how to provide a system with which the application can trigger a logout. Morgan observes that when most popular browsers receive the 401 Unauthorized error code, they immediately launch the authentication pop-up window, regardless of whether the user was already logged into the site. But this behavior is not specified in the HTTP standard; if browsers simply checked for existing credentials in the cache, a 401 could be used to trigger a logout in the event that the user is logged in, and prompt for credentials if the user is not logged in.
He also suggests another solution, a new HTTP header called "Authentication-Control" that could be used to terminate a session from the web server.
The paper outlines several practical problems that would come with attempting to migrate to digest authentication for session management. To begin with, digest authentication is so rarely used that its implementation in popular web servers and web browsers is immature. Just as bad, today's browsers have weak, bare-bones user interfaces for HTTP authentication. Password managers do not differentiate between credentials stored for HTTP sites and those stored for HTTPS, making man-in-the-middle attacks possible.
The authentication pop-up windows are also sparse in their presentation, offering confusing messages that make phishing attacks possible. Morgan shows example windows from Internet Explorer, Firefox, Safari and Opera, in which the "realm" value sent in the authentication request is used to display an intentionally-misleading message to the user.
Finally, Morgan notes, because application developers have relied on
cookie-based session management for several years, they have become
accustomed to the application framework handling session management.
Switching to digest authentication would mean relying on the web server to
manage the session authentication, and that change could meet with
Morgan posted news of the paper to Bugtraq, Full Disclosure, and several other security mailing lists in January. Reaction was mixed; while most agreed with the technical arguments, some thought that the paper did not explain how important web application functionality — namely SSO — could be made to work with digest authentication. The strongest disagreements, however, came from those who argued that the amount of coding and refactoring required to change web application frameworks' authentication systems make the entire argument moot.
The proposal did receive a friendlier reception in mozilla.dev.security, however, where Mozilla's Dan Veditz pointed out similar work on improving web authentication going on at Mozilla Labs.
to post comments)