Security

Should web developers say no to cookie-based authentication?

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 also points out several flaws with cookie-based session IDs at the protocol level. First, a cookie originally sent on HTTPS will also be sent over HTTP on subsequent requests, unless the web developer takes the proactive step of setting the "secure" flag on the cookie, which few application frameworks do. Second, by default stored cookies are available to client-side JavaScript, making them vulnerable to theft via cross-site-scripting attacks. Internet Explorer and Firefox both feature an "HttpOnly" cookie flag to block this behavior, but other browsers do not, and few session-management frameworks have adopted it. Failure to automatically time-out sessions and poorly-implemented single sign-on (SSO) methods also make many cookie-based session management schemes vulnerable.

Digest

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.

Practical problems

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 resistance.

Reaction

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.

Will web developers be weaned off of their cookie addiction? Presumably that hinges on whether the popular application frameworks undertake the task of replacing cookies as a session-tracking tool. Morgan argues in the paper that because cookies are widely used for many general-purpose tasks, asking them to correctly implement secure authentication is a losing battle: other concerns, from marketing to SSO, will always be more popular, and get the lion's share of developer attention. But it is interesting to note that an almost-complete, more secure solution already exists in the standards. Perhaps decoupling authentication and cookies would be a quicker process than the naysayers believe.

Comments (13 posted)

Brief items

Blaze: The Spy in the Middle

Comments (30 posted)

New vulnerabilities

asterisk: denial of service

Comments (none posted)

curl: denial of service

Comments (none posted)

glpi: cross-site scripting

Comments (none posted)

ikiwiki: cross-site scripting

Comments (none posted)

krb5: denial of service

Comments (none posted)

mediawiki: information disclosure

Comments (none posted)

php5: denial of service

Comments (none posted)

puppet: temporary file vulnerability

Comments (none posted)

qt: multiple vulnerabilities

Comments (none posted)

samba: symbolic link vulnerability

Comments (none posted)

spamass-milter: arbitrary shell execution

Comments (none posted)

thunderbird: denial of service

Comments (none posted)

thunderbird: arbitrary code execution

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>