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

Password crack [affecting OAuth and OpenID] could affect millions

computerworld.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Password crack [affecting OAuth and OpenID] could affect millions

#41

Post by tptacek »

metachris wrote: post #35
tptacek wrote: post #11

Earlier quoted context omitted.

Yes, systems that hash passwords aren't timeable, because attackers can't "propose" a hash that is correct to the first N bytes in order to find byte N + 1. If you are comparing literal passwords, you may have something more to be concerned about.

For websites yes, but often you want to transmit the hashed value over the network. In that case it might be easier to implement the constant-time comparison. Python: def is_equal(a, b): if len(a) != len(b): return False result = 0 for x, y in zip(a, b): result |= x ^ y return result == 0 Java: public static boolean isEqual(byte[] a, byte[] b) { if (a.length != b.length) { return false; } int result = 0; for (int i =…

It is a bad idea to send hashed passwords over a network. If you need a level of security beyond "passwords on the wire", use TLS.

Re: Password crack [affecting OAuth and OpenID] could affect millions

#42

Post by tptacek »

amalcon wrote: post #28
tptacek wrote: post #11

Earlier quoted context omitted.

Yes, systems that hash passwords aren't timeable, because attackers can't "propose" a hash that is correct to the first N bytes in order to find byte N + 1. If you are comparing literal passwords, you may have something more to be concerned about.

"Not timeable" isn't entirely accurate. There are still ways to make use of timing information; they are just not this particular textbook example.

Be more specific about the attack you're thinking of?

Re: Password crack [affecting OAuth and OpenID] could affect millions

#43

Post by daeken »

tptacek wrote: post #42
amalcon wrote: post #28

Earlier quoted context omitted.

"Not timeable" isn't entirely accurate. There are still ways to make use of timing information; they are just not this particular textbook example.

Be more specific about the attack you're thinking of?

I may be wrong on this, but if you know the mechanism by which it's hashed, then there should be nothing stopping you from doing the hashing on your side as well, and timing the hash comparison. So if 'foo' hashes to 'abcdef' and 'bar' hashes to 'ab0012', and it takes longer for 'bar' to be checked than 'foo', that tells you something about the hash it's comparing against. Obviously in the real world this is significantly more difficult as it's tough to generate data that hashes to what you want it to, but I don't see why such an attack wouldn't be possible.

(Of course, this could be completely different than what the parent was thinking about.)

Re: Password crack [affecting OAuth and OpenID] could affect millions

#44

Post by NateLawson »

Hi, we're the ones who were interviewed for this article. First, the article has been updated (including headline, which now reads "Authentication crack..."). The author mistakenly focused on the fact that OAuth and OpenID are used for authentication, and thus substituted "password" for "token" in his head when we explained things. I'll have to work on speaking more clearly. :-)

The attack is not new. But it's still everywhere. That's why we're giving a talk at Blackhat. We are hoping this will finally be the year people take timing attacks seriously and fix them.

The point of our talk is to give concrete numbers to let people make their own decisions about exploitability. One result is a matrix of language (C, Java, Ruby, Python, PHP) versus attacker vantage point (Internet, LAN, VM-to-VM on same host). We'll show the minimum timing delta we were able to distinguish at each point, given a certain number of samples.

The previous best results in this area were 20 microseconds Internet, 100 nanoseconds LAN with about 1000 measurements (Crosby et al). We have improved a bit on this (too soon to give exact numbers, wait for the talk).

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

Nearly every OAuth and OpenID library we found was vulnerable. No one has fixed these kinds of things. That's sad because they are exploitable in some configurations and as a software developer, you never fully know your customer's threat model. They could be running on Slicehost and have attackers literally on the same machine or a single server on a WAN link locked in a vault. (Usually the former more than latter.)

We hope our talk helps developers take this kind of attack more seriously but also dispel some of the FUD that these are easy. I think a good conclusion to make is "timing attacks are easier than I expected (but not easy) so it's worth fixing them."

Re: Password crack [affecting OAuth and OpenID] could affect millions

#45

Post by NateLawson »

SoftwareMaven wrote: post #32
twp wrote: post #23

Earlier quoted context omitted.

From my understanding, actually surprisingly so. Stats allow you to cope with latency and uncertainty - just ask the NTP gurus. There's a reference somewhere, but effectively these attacks are possible over surprisingly long distances/dodgy connections.

And even more so, with people potentially sitting right next to each other on services like AWS, RackSpace, etc.

See "Get off my cloud" for an example how you can exploit the allocation algorithms to intentionally locate yourself on the same machine as your target.

http://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf [pdf]

Re: Password crack [affecting OAuth and OpenID] could affect millions

#46

Post by NateLawson »

tptacek wrote: post #42
amalcon wrote: post #28

Earlier quoted context omitted.

"Not timeable" isn't entirely accurate. There are still ways to make use of timing information; they are just not this particular textbook example.

Be more specific about the attack you're thinking of?

Timing leaks about a password hash can eliminate potential guesses from your dictionary, making a combined online/offline attack marginally more powerful. However, it does not directly reveal the password as it would if they were plaintext.

Re: Password crack [affecting OAuth and OpenID] could affect millions

#47

Post by NateLawson »

tptacek wrote: post #8
LiveTheDream wrote: post #6

This timing attack is really old news, but subtle enough to persist in many a project, e.g. Rails patched it in v2.3.4 Sept 09 (briefly re-introduced it this month on edge). Will be interesting to see which of the big players were shown to be vulnerable.

This is an extremely dangerous attitude towards a vulnerability class . Rails did not fix the timing comparison of an OpenID HMAC verification; they fixed a timing bug in the HMAC comparison function of the Rails message verifier, which is used by session cookies and cannot be used for OpenID. This misconception is dangerous because old vulnerability classes are extremely pernicious and have a terrible habit of reapp…

I agree it's old news that these things are exploitable. But nobody fixed them. So either developers don't care about exploitable flaws or they aren't aware they're exploitable. The latter is the reason for the talk.

Re: Password crack [affecting OAuth and OpenID] could affect millions

#48

Post by NateLawson »

amalcon wrote: post #30
snprbob86 wrote: post #25

Earlier quoted context omitted.

So then is the fix as simple as removing the early "break;" statement from a strcmp?

Depends on the rest of the strcmp implementation. You might still leak information such as the number of correct characters if responding to a correct character takes a different amount of time than responding to an incorrect character. Ever played Mastermind? Same theory here. Your best bet is to generate a huge body of inputs (including the relevant special cases), and tweak the code until it takes the same amount…

Number of chars would matter for plaintext passwords but not HMAC. You gain no more practical advantage knowing I used SHA1 or SHA256 HMAC. Yet another reason not to use plaintext passwords.

Re: Password crack [affecting OAuth and OpenID] could affect millions

#49

Post by [deleted] »

metachris wrote: post #35
tptacek wrote: post #11

Earlier quoted context omitted.

Yes, systems that hash passwords aren't timeable, because attackers can't "propose" a hash that is correct to the first N bytes in order to find byte N + 1. If you are comparing literal passwords, you may have something more to be concerned about.

For websites yes, but often you want to transmit the hashed value over the network. In that case it might be easier to implement the constant-time comparison. Python: def is_equal(a, b): if len(a) != len(b): return False result = 0 for x, y in zip(a, b): result |= x ^ y return result == 0 Java: public static boolean isEqual(byte[] a, byte[] b) { if (a.length != b.length) { return false; } int result = 0; for (int i =…

[deleted]

Re: Password crack [affecting OAuth and OpenID] could affect millions

#50

Post by michaeltwofish »

tptacek wrote: post #10

Everyone who reads HN is smart enough to simply read the primary source for this: http://lists.openid.net/pipermail/openid-security/2010-July/... Follow the thread. Nate is Root Labs, Taylor works for him. This is the same vulnerability as Nate found in Google Keyczar last year, and that Coda Hale found in Rails several months ago. Until people start handling crypto flaws the same way we handle buffer overflows, swee…

Thanks for the link. There's nothing quite as educational as watching experts discuss a topic.
Post reply on HN