3 ms·

> Even with a more optimized program, I'd be surprised if "fairly easy" were an accurate characterization of the effort to separate timing of comparing one extr

> Even with a more optimized program, I'd be surprised if "fairly easy" were an accurate characterization of the effort to separate timing of comparing one extra character of a password from all the other stuff going on during a request: database access, routing, parsing query parameters, load from other requests, garbage collection pauses, network latency... The signal-to-noise ratio is just too low. Timing attacks are possible over networks, even when the timing differences are minuscule. [1] [1] http://www.usenix.org/events/sec03/tech/brumley/brumley_html/ http://www.usenix.org/events/sec03/tech/brumley/brumley_html...

ericlavigne 16y ago
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/ 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.

ericlavigne 16y ago

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/ 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.