Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Timing Attack In Action

verboselogging.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: A Timing Attack In Action

#11

Post by dekz »

MSM wrote: post #10
darkhelmetlive wrote: post #5

Earlier quoted context omitted.

It can work the same way. You just slowly figure out the hash: this pw for this user was a bit faster than all the other failures, so we know the first byte of the hash is ... 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.

This makes sense, I hadn't thought of knowing the hashing method and it being unsalted. Knowing those it would be just as easy to whittle the list down exactly the same way.

Err, not exactly the same way. Sure if you have a rainbow table of all the possible values of the hash construct then it would take a negligible amount of time. Doing the math of all possible values in the Hash space you will quickly see that at this point in time and space it's not plausible to have that.

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.

Re: A Timing Attack In Action

#12

Post by colonelxc »

darkhelmetlive wrote: post #4
aidenn0 wrote: post #2

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.

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?

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

Re: A Timing Attack In Action

#13

Post by darkhelmetlive »

colonelxc wrote: post #12
darkhelmetlive wrote: post #4

Earlier quoted context omitted.

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?

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

Awesome, thanks!

Re: A Timing Attack In Action

#14

Post by darkhelmetlive »

aidenn0 wrote: post #6
darkhelmetlive wrote: post #4

Earlier quoted context omitted.

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?

http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

Awesome, thanks! Added this and the other one to the post.

Re: A Timing Attack In Action

#15

Post by pacaro »

MSM wrote: post #3

How does this work with hashed passwords? Wouldn't any semblance of avalanche effect make this attack useless?

Looking at the bigger picture of login/auth, timing might easily tell you the difference between valid and invalid usernames (information that you would not normally expect to leak from login)

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.

Re: A Timing Attack In Action

#16

Post by brl »

colonelxc wrote: post #8
MSM wrote: post #3

How does this work with hashed passwords? Wouldn't any semblance of avalanche effect make this attack useless?

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…

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.

Post reply on HN