Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's an interesting article. While I feel less certain of my original position, I am still skeptical about a timing attack based on the time required to compare two password strings for equality.

Note that while the article deals with similar sources of noise, it also deals with a larger signal. They are trying to time a decryption process, which has a high computational complexity by design. We are talking about timing the difference between checking for equality of the first few characters of a string, versus checking for equality between all characters of strings that are unlikely to be more than 20 characters long.

Chrome tells me that it took 109 milliseconds to load a 50-line stylesheet on my personal website.

http://ericlavigne.net/

A quick and dirty experiment showed that the following comparison of short strings takes between 3.5 and 5.9 milliseconds for 10,000 runs.

(def partial-password "abra")

(def guess1 "abrab")

(time (dotimes [i 10000] (= partial-password guess1)))

Whereas a similar comparison of longer strings takes between 5.8 milliseconds and 6.0 milliseconds.

(def password "abrakadabra")

(def guess2 "abrakadabl")

(time (dotimes [i 10000] (= partial-password guess1)))

So the operation we are trying to time shows a lot of variability even if you can isolate it by running that code directly in a terminal, and a typical small HTTP response takes up about a million times more runtime.

Yes, these are very crude estimates. Good profiling is much harder than this. Still, if I knew this was the only security hole in my application, I'd be feeling very safe.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: