On Jul 26, 2010, at 12:17 AM, Neil Schemenauer wrote:

> Lately I've been worried that Quixote (and most likely qp) are
> vulnerable to a timing attack[1] against the session cookies.
> Thinking about it today, I'm pretty sure the hash of the session
> dictionary does not save us and the current scheme is vulnerable.
>
> For those who don't know, the dictionary hash tells Python the entry
> in the table to check.  A byte-by-byte compare is done on the result
> to confirm the key matches.  I imagine a successful attack would
> proceed as follows:
>
>   1. try a sequence of session IDs and analyze the timing to
>      find a key to hashes to an existing session ID's table
>      entry
>
>   2. using knowledge of the dictionary hash function, generate a
>      sequence of session IDs that hash to the same entry, finding
>      each byte of the session ID based on the timing.
>
> Step 2 is obviously more complicated depending on the hash function
> used.  I'm out of my depth here, but I think using a cryptographic
> hash on the session ID before storing it would solve the problem.
>
> Another idea would be to introduce a session password.  The ID would
> be used to lookup the session object and the password would be
> verified using some constant function.  Any other thoughts or ideas?
>
> BTW, it looks like the user password hash used by qp is pretty poor.
> It should not be using MD5 unless a protocol requires it.

I think HTTP Digest Authentication does require MD5 and that
is why it is used in qp.

What if hash lookup failures do no return until they have completed
a randomized time-obscuring operation?

> Also,
> using a better salt value and "stretching" would be advisable[2].
>
>
>    Neil
>
> 1. http://codahale.com/a-lesson-in-timing-attacks/
> 2. http://python.ca/nas/log/200812/index.html#08_001
> _______________________________________________
> Quixote-users mailing list
> Quixote-users@mems-exchange.org
> http://mail.mems-exchange.org/mailman/listinfo/quixote-users