2
$\begingroup$

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?

$\endgroup$
4
  • $\begingroup$ What is gained by tying the session cookie to the user's password in any way? $\endgroup$ Commented Aug 26, 2014 at 23:49
  • $\begingroup$ 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. $\endgroup$
    – smang
    Commented Aug 26, 2014 at 23:53
  • 3
    $\begingroup$ 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. $\endgroup$ Commented Aug 27, 2014 at 0:37
  • $\begingroup$ Haha, it seems so simple now. I can't believe I missed that. Thank you! $\endgroup$
    – smang
    Commented Aug 27, 2014 at 1:47

1 Answer 1

2
$\begingroup$

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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.