« WASC RSA Meet-Up 2010! | Main | Nikto version 2.1.1 released »

Weaning the Web off of Session Cookies Making Digest Authentication Viable

Timothy D. Morgan has published an excellent paper describing

  • How UI limitations hinder adoption of HTTP based authentication
  • How UI behaviors are/can be abused pertaining to HTTP auth
  • Observations on Cookie limitations
  • Proposals for browser vendors to allow for more widescale adoption of HTTP based auth such as digest

From the paper

"In this paper, we compare the security weaknesses and usability limitations of both cookie based session management and HTTP digest authentication; demonstrating how digest authentication is clearly the more secure system in practice. We propose several small changes in browser behavior and HTTP standards that will make HTTP authentication schemes, such as digest authentication, a viable option in future application development."

One of the better papers I've read in a long time and certainly worth checking out if you consider yourself an HTTP haxor.

Paper: http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.


All Comments are Moderated and will be delayed!



Hello.

I personally like the flexibility of PHP application based security.

The CMS that I've been working on uses a dispatch system with the entire site accessed from the same URL. Authentication is performed and then combination of include filename and function name are derived from the page id passed as a POST field. The PHP eval function is then used to execute the code for the requested page. There's an includes table, a pages table and a permissions table that links user id to page id, and for the dispatch to get to the point where it evals the page code the page access permission must be authenticated for the logged in user.

The site has three means of authentication:
1. login form, where user name and password are passed as POST fields
2. session id, which after login is output as a hidden field in every form, and is a psuedo-random 255 character string (not SHA) that is unique in the MySQL user table (PHP sessions are'nt used)
3. persistent cookie with session id (as per means 2 above) instead of as a hidden field in every form

With cookie login, an identifier can be passed as a GET field (for use in favourites/hyperlinks) and a page id derived from a record in MySQL with that identifier/user authentication.

Also, with hidden POST field session id, the id is renewed on each page request (to prevent session hijacking).

The whole system was designed around not just security but also development efficiency/flexibility/scalability (including universal authentication system and code modularity).

I have a page with a javascript-driven hyperlink tree structure (although I usually try not to use javascript if I can avoid it) and an iframe, and when the user clicks on one of the tree nodes, information about that node is presented in the iframe. The reason for going with an iframe was so that the node visibilities aren't reset by a page refresh.

The problem that I'm working on at the moment (which led me to this page) is that the iframe content needs to be authenticated like the parent page, but with the hidden POST field based session id, the first time I click on a tree node, the page in the iframe is authenticated but the session id is renewed such that all the session ids in the parent page are invalidated.

I've thought of override systems and flags, but I don't want a patch fix and I want to stick with my design philosophy of development efficiency/flexibility/scalability (there may be two iframes in a page for example).

Something I thought of as I was writing this is to pass the tree node visibility statuses as hidden POST fields, but not only would that blow out the size of the page exponentially with the number of nodes, but the user would have to wait for the entire page (parent and iframe) to load after each node is clicked.

If anyone has an idea of how to approach this problem, feel free to post it here.

I know the more complex the system is the higher risk there is of bugs that may lead to security holes, but for my application protection of client data against unauthorised access is paramount.

Cheers.


1. No need to design yet another login screen, or HORROR of HORRORS, use a 3rd party one.

2. Digest supports time-out which is how most cookie sessions end anyway.

3. Apache mod_digest + mod_authn_dbd implements digest that will work with 99% of browsers, and practically drop-in-replace most existing cookie solutions.

No extra coding. You can take the day off.

Post a comment







Remember personal info?