Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question
    
What is gained by tying the session cookie to the user's password in any way? –  Stephen Touset Aug 26 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 at 23:53
2  
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 at 0:37
    
Haha, it seems so simple now. I can't believe I missed that. Thank you! –  smang Aug 27 at 1:47

1 Answer 1

up vote 1 down vote accepted

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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