

A Timing Attack In Action - darkhelmetlive
http://verboselogging.com/2012/08/20/a-timing-attack-in-action

======
aidenn0
Something not mentioned here is that timing attacks have been proven effective
even across the internet; you might think "Oh the jitter in TCP is going to
overwhelm any leaked information," but you would be wrong.

~~~
darkhelmetlive
I do have the sentence "This difference is enough to measure, even on web
applications." in the fourth paragraph. Should I highlight that a bit, bold
maybe?

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?

~~~
colonelxc
<http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf>

~~~
darkhelmetlive
Awesome, thanks!

------
dekz
If you're comparing plain text passwords then you've already done something
wrong. You'll find the hash construct mitigates against attacks like these due
to its nature, especially with a per user salt.

------
MSM
How does this work with hashed passwords?

Wouldn't any semblance of avalanche effect make this attack useless?

~~~
colonelxc
Hashing would make this technique less useful, but not necessarily useless.
For instance, if there is no salt involved, and the hashing algorithm is known
(or guessable), you can still make some use of the information leaked.

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.

~~~
brl
If your salt is 'short' you can still perform this attack.

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.

------
mdonahoe
Your post was hard to read because of your background image
[http://cf.verboselogging.com/assets/headshot-44822a75dfeaa89...](http://cf.verboselogging.com/assets/headshot-44822a75dfeaa891c3bb14b64f75f7fc.jpg)

