Practical Uses for Timing Attacks on Hash Comparisons (e.g. MD5)? Consider the following code snippet:

&lt;?php
session_start();
if (md5($_POST['password']) === '550b1f8802ca3d7a987fc46a2af408c3') {
         $_SESSION['loggedIn'] = true;
}
header("Location: /");
exit;


If an attacker doesn't know the hash, they should still be able to leak bits of the hash via timing information (and by knowing the hashing strategy employed).

If you send thousands of requests and study the MD5 hash you transmit (as well as the timing information) of various passwords, you should be able to deduce the first N hexits of the hash. Then, using a client-side brute force search against this known information, optimize your online guessing by discarding a large number of guesses.

Even deducing the first 4 bytes can cut your guess time down by a factor of a billion.

That said, has anyone published any research in this area? Specifically, exploiting a partial leak via timing information and using it to guess passwords against unknown hashes faster.

Would this be worth researching at all?
There is no timing attack possible on MD5 as practically implemented on most platforms. That's because MD5 uses only 32-bit addition, 32-bit bitwise boolean operators, and constant rotations/shifts, which exhibit no data-dependent timing for any reasonable implementation, even written without consideration for resistance to timing attacks.

There is however a conceivable timing attack, unrelated to MD5, on the code shown (which is PHP, but that holds in many other languages, with minor variants), aiming at finding the first few characters of the hash value if that's unknown (the equivalent of the constant 550b1f8802ca3d7a987fc46a2af408c3 in the code sample). Assuming the string comparison of === is performed from left to right, character by character, and stopping on the first non-matching character, there can be a timing attack on the string comparison: if on average the password test1 (hashing to 5a1…) is rejected significantly slower than test0 (hashing to f6f…) and test2 (hashing to ad0…), then the true hash of the password can safely be assumed to starts in 5. We can then find and time the rejection of other test passwords which hash starts in 5 (like test8 hashing to 5e4…) to try find the second character of the hash; and so on. In this way we need to perform (significant) timing measurements for at most 32×16 well-chosen test passwords in order to find the whole hash.

That's fine in theory. In practice the attacker trying this will face at least two hurdles:


The difference in timing is very small, and a variety of things will conspire to mask it: network delays, other tasks and how they left the various CPU caches, numerous clocks on the hardware..; in order to make any progress, the attacker will need an awful lot of measurements, a direct network connection, a low-load server, and a sound strategy (like considering the average of observed times for a given test password after some setup-dependent filtering, perhaps keeping the few lowest measurements if all the accidental masking factors are additive).
Finding the leftmost $n$ characters of the hash requires about $2^{4n}$ evaluations of MD5 in order to find the test passwords to be timed; with $2^{60}$ evaluations (which is already requiring serious effort), the attacker only gets 12 characters (60 bits) out of 32 (128 bits).


If the first of these two hurdles can be overcome, the method has a benefit: the attacker can explore test passwords according to a synthesized list of candidate passwords approximately by decreasing likelihood, so that a low-entropy password will be found with (hopefully) fewer online queries to the server than without the timing attack; and no more offline hashes than required for a brute force attack with the hash known, even though the attack is performed without the hash.

I would be slightly surprised if that was a real threat for any server accessed through a few network hops; and I'm unsure this is worth academic publication in a first-tier conference or journal.