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?

I don’t store the full password hash in the cookie. Depending on the protocol variant, it’s either an encrypted version or the hash with salt removed. This means it’s not feasible to brute-force the password from the cookie.

The reason I store this in the cookie is that it’s something a server can verify but cannot create. You can only generate it with the password, which is not stored in the database and is discarded immediately after the password is checked and cookie generated.

I’ve described why session IDs are not desirable in Section 1.2 of the paper. The key problem is that the session table grows with the number of open sessions, not the number of users. This increases storage, makes load-balancing more difficult and creates additional vulnerabilities to DoS.

There are a few differences between my approach and that of Wordpress.

Firstly, I’ve described my scheme and the rationale in a paper at a peer-reviewed conference. This gives researchers an opportunity to find flaws and suggest improvements.

Secondly, I only started to develop my scheme after looking for existing proposals which gave the same security guarantees. In contrast, the Wordpress system has far poorer security than the standard solutions.

Thirdly, I based my proposal on an existing scheme and was careful to avoid introducing new vulnerabilities. This significantly increases the chance that it is secure.

Someone has to design protocols, but only when necessary. Wordpress invented their own because they either did not look at, or ignored, the existing literature. They also took the wrong approach in the design process. It’s therefore not surprising that their system was insecure.

Good point; I’ve clarified that sentence.