I recently came across an interesting paper detailing the use of hardened session cookies. Each cookie includes a preimage of the password hash, and the preimage is hashed once more and compared to the stored password hash as part of the cookie authentication process.

In order for this to work, we must be able to quickly compute the password hash from the preimage on each web request. This is not easily possible using plain PBKDF2-SHA256 to store the passwords. However, if we store the passwords as:

$SHA256(PBKDF2(password, salt, iterations=10000))$

we can quickly move from the preimage, $PBKDF2(password,salt,iterations=10000)$, to the stored hash by computing $SHA256(preimage)$.

What are the relative weaknesses here, compared with just storing the PBKDF2-SHA256 digest?

• What is gained by tying the session cookie to the user's password in any way? – Stephen Touset Aug 26 '14 at 23:49
• If the database is exposed (SQL injection, etc.), the attacker cannot generate cookies (unless they know the user's password). I am also assuming the cookies are transported over https. – smang Aug 26 '14 at 23:53
• That's also possible by storing a random key in the user's cookies and comparing it against the hash of that key in the database. Or by HMACing the session cookie with an in-memory key. – Stephen Touset Aug 27 '14 at 0:37
• Haha, it seems so simple now. I can't believe I missed that. Thank you! – smang Aug 27 '14 at 1:47

Thanks to @Stephen Touset for the solution.
In order to avoid tying the session cookie to the user's password (and avoid using PBKDF2-SHA256+SHA256), we can simply create a random $key$ for the user upon login. $SHA256(key)$ is then stored in the db, along with a session ID that ties the session to a specific user.
$key$ is then used as the preimage in the session cookie. Upon each request, we calculate $SHA256(key)$, and compare it to the value stored in the db.