Re: [Quixote-users] Timing attacks against session cookies
Binger David <dbinger-fVcApmY9cLvQ3/1i3zOLAti2O/[email protected]> Mon, 26 Jul 2010 10:08:18 -0400
| Newsgroups | gmane.comp.python.qp,gmane.comp.web.quixote.user |
|---|---|
| Message-ID | <[email protected]> |
--===============0918591934== Content-Type: multipart/alternative; boundary=Apple-Mail-3--949095979 --Apple-Mail-3--949095979 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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-fVcApmY9cLvQ3/1i3zOLAti2O/[email protected] > http://mail.mems-exchange.org/mailman/listinfo/quixote-users --Apple-Mail-3--949095979 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br><div><div>On Jul 26, 2010, at 12:17 AM, Neil Schemenauer = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div>Lately I've been worried that Quixote (and most = likely qp) are<br>vulnerable to a timing attack[1] against the session = cookies.<br>Thinking about it today, I'm pretty sure the hash of the = session<br>dictionary does not save us and the current scheme is = vulnerable.<br></div></blockquote><blockquote type=3D"cite"><div><font = class=3D"Apple-style-span" color=3D"#000000"><br></font>For those who = don't know, the dictionary hash tells Python the entry<br>in the table = to check. A byte-by-byte compare is done on the result<br>to = confirm the key matches. I imagine a successful attack = would<br>proceed as follows:<br><br> 1. try a sequence of = session IDs and analyze the timing to<br> = find a key to hashes to an existing = session ID's table<br> entry<br><br> = 2. using knowledge of the dictionary hash function, generate = a<br> sequence of session IDs that hash to = the same entry, finding<br> each byte of = the session ID based on the timing.<br><br>Step 2 is obviously more = complicated depending on the hash function<br>used. I'm out of my = depth here, but I think using a cryptographic<br>hash on the session ID = before storing it would solve the problem. = </div></blockquote><blockquote type=3D"cite"><div><br>Another idea = would be to introduce a session password. The ID would<br>be used = to lookup the session object and the password would be<br>verified using = some constant function. Any other thoughts or ideas?<br><br>BTW, = it looks like the user password hash used by qp is pretty poor.<br>It = should not be using MD5 unless a protocol requires it. = </div></blockquote><div><br></div><div>I think HTTP Digest = Authentication does require MD5 and that</div><div>is why it is used in = qp.</div><div><br></div><div>What if hash lookup failures do no return = until they have completed</div><div>a randomized time-obscuring = operation?</div><div><br></div><blockquote = type=3D"cite"><div>Also,<br>using a better salt value and "stretching" = would be advisable[2].<br><br><br> Neil<br><br>1. <a = href=3D"http://codahale.com/a-lesson-in-timing-attacks/">http://codahale.c= om/a-lesson-in-timing-attacks/</a><br>2. <a = href=3D"http://python.ca/nas/log/200812/index.html#08_001">http://python.c= a/nas/log/200812/index.html#08_001</a><br>________________________________= _______________<br>Quixote-users mailing list<br><a = href=3D"mailto:Quixote-users-fVcApmY9cLvQ3/1i3zOLAti2O/[email protected]">Quixote-users@mems-exchang= e.org</a><br>http://mail.mems-exchange.org/mailman/listinfo/quixote-users<= br></div></blockquote></div><br></body></html>= --Apple-Mail-3--949095979-- --===============0918591934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ QP mailing list QP-fVcApmY9cLvQ3/1i3zOLAti2O/[email protected] http://mail.mems-exchange.org/mailman/listinfo/qp --===============0918591934==--