A Timing Attack In Action
verboselogging.com
verboselogging.com
I'd also like a good reference for that, and my Google skills were failing me. Do you happen to have a link to something show that off?
Wouldn't any semblance of avalanche effect make this attack useless?
If you have a bunch of hashes precomputed, you can start to figure things out pretty quick.
The point is it's still leaking information about what's going on.
You may then argue that you can have the value space of all popular passwords, but that isn't going to be any more effective than just trying all of the possible passwords.
The difference is that you are not being leaked information about the password, but about the hash of the password. One problem with trying to brute force an authentication over the internet is that it is slow and potentially noticeable by the server admin (then you get cut off). If you exploited a timing attack from a comparison between raw md5's or sha1's of a password, then you can use the leaked information to focus your brute force. Basically, you could use a rainbow table to help you pick what passwords to try next, getting a lot more bang for your buck. In this way you can use the combination of offline brute forcing to generate possible hashes, and the timing attack to select which passwords to actually send.
Now an unknown salt would still ruin your day, just like it is designed to make life difficult for rainbow tables in the first place.
Assume a timing oracle, which when queried with a plaintext password will return an integer which is the length in bytes of the matching hash prefix.
Choose a small prefix length (perhaps 3 or 4) and send distinct passwords to the oracle until you have more than one input password which produces the length you've chosen.
With this information you can perform an offline brute force of all possible salt values to reduce that set to only the salts which produce the correct matching prefixes when used with the passwords from the previous step.
Too many salts in this set? Test each one by generating a candidate password that has the same prefix as your test cases and then ask the oracle if it agrees that the prefixes match.
Once you know the salt, perform a dictionary attack against the partial hash you already know from guessing the salt to create a set of candidate passwords. If there are too many passwords to test them all, then generate a longer prefix. Either trying all the passwords or generating a prefix which is one byte longer than the last one is going to be a harder problem. Choose the easier of the two problems at each iteration.
A clumsy password implementation may give away information about valid password rules, imagine a system that validates passwords for length/complexity etc. (either before or after hashing) and rejects based on that, without comparing the hash values (or worst case, without even performing the hash) again more information has been leaked in the timing.