One thing I don’t understand is why you don’t use a HMAC internally?

Does the iteration of the functions a^n…a^0 protect against attacks, such as appending bytes to a known message?

That would give better resistance, but would only allow one user session to be active at any time. I wanted to permit a user to be logged in from both home and work. If the MAC key was rotated, logging out of one would invalidate the cookie for the other session.

The MAC key seems like the weakest link in the system. Given the MAC key, any intercepted cookie can extended to work forever, and the only way to revoke it is to change the MAC key (which revokes all cookies), or for the user to change their password.

What if, instead of a global MAC key, there was a user specific MAC key (stored in the DB) that was rotated every time the user did a manual logout. That would invalidate all old cookies, and would allow for user at a time key rotation.

I think it would be sort of like the “token” part of this system: http://jaspan.com/improved_persistent_login_cookie_best_practice

(I know that’s about auto-login cookies, not stateless session cookies, but it’s similar)

The iterated hashing is to increase the cost of a brute-force password discovery attack by someone who has obtained a copy of the password database. It is a standard component of password hashing schemes, for example Bcrypt.

HTTP Digest Auth requires that the server either store the cleartext password or H(A1) = MD5(username . ‘:’ . realm . ‘:’ . password). Including the username and realm in the hash is better than nothing, but it’s not as secure as including a salt.

For example, it’s apparent when a user has changed their password back to an old value. Things may also go wrong if fields contain the “:” character.

Also, MD5 is applied only one time. This makes it easier to brute-force the password when compared to standard password hashing schemes built around an iterated hash.

It also suffers from the same problem as the Fu et al. paper, which my proposal tries to fix. Namely, if you get access to the authentication database, containing H(A1), you can spoof a HTTP Digest authentication response.

It at least used to be the case that Microsoft products (IIS and Internet Explorer) implemented a different and incompatible version of the HTTP Digest standard to Apache and Firefox. I don’t know if this has been fixed, but if not that effectively eliminates the usefulness.

From a usability perspective, there’s also the problem that the dialog box offered by browsers for Digest and Basic authentication is not customizable. This also reduces the attractiveness of these options when compared to HTML form password boxes.

Both retransmit full auth info with each requests (instead of just an ID in the case of session cookies). But with digest auth, passwords are never sent in clear text…

As far as I know, digest auth is implemented in all major browsers (baring some microsoftism in IE). Why not use that instead of cookies?