Password crack [affecting OAuth and OpenID] could affect millions • Hacker News Board

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

#51

Post by caf » Sat, Jul 17, 2010, 6:58 AM UTC

gmonroe wrote: post #36

tptacek wrote: post #13

Earlier quoted context omitted.

The funniest part about these discussions is that we're discussing an optimization that exclusively helps attackers . Virtually all HMAC candidate hashes are correct all the way through the final byte, meaning that even in a classic short-circuited compare, you still have to read everything. In virtually all traffic, you never get to take that short circuit. The only time short-circuited comparisons ever make things…

However, in many high-level languages == is written in C, and reimplementing it in the high-level language can be quite slow in comparison.

You know, it'd be handy if such high-level languages implemented a separate =$= operator that worked just like ==, but was timing-independent.

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

#52

Post by hysterix » Sat, Jul 17, 2010, 7:12 AM UTC

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…

Thank you very much for that link. I've been looking for more information than what the lame article gives and the link is just awesome.

Thanks.

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

#53

Post by hysterix » Sat, Jul 17, 2010, 7:15 AM UTC

NateLawson wrote: post #44

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…

You guys are out of control over there. Wish I could be there personally at your presentation.

You are awesome

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

#54

Post by metachris » Sat, Jul 17, 2010, 10:48 AM UTC

tptacek wrote: post #41

metachris wrote: post #35

Earlier quoted context omitted.

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.

Yes I fully agree. But sometimes you can't always use SSL/TLS (eg. for performance reasons within games). For certain requests you might want to add a hash for integrity protection and in that case absolutely use constant-time comparisons.

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

#55

Post by pvg » Sat, Jul 17, 2010, 12:43 PM UTC

NateLawson wrote: post #44

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…

We have improved a bit on this (too soon to give exact numbers, wait for the talk).

Can you, at this point, give us any idea whether the lower bound of 'a bit' is, say, single digit percent or a factor of two or whatever the case might be?

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

#56

Post by julian37 » Sat, Jul 17, 2010, 12:50 PM UTC

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 =…

I might be missing something, but wouldn't that code allow to guess the password length because it returns more quickly if the length doesn't match? As far as I can see, the following would give away less information:

  def is_equal(actual, submitted):
      result = 0
      for i in range(0, len(submitted)):
          result |= ord(actual[i % len(actual)]) ^ ord(submitted[i])
      return result == 0 and len(actual) == len(submitted)

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

#57

Post by JoeAltmaier » Sat, Jul 17, 2010, 1:55 PM UTC

Groxx wrote: post #16

thrill wrote: post #2

if timing is so critical to these attacks, it seems adding a tiny variable (on the order of a millisecond) in response times would completely prevent this

That effectively already exists. The internet isn't instant or consistent, and this is about remote timing attacks.

The internet is Statistically consistent, which is all the attack needs.

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

#58

Post by brown9-2 » Sat, Jul 17, 2010, 2:58 PM UTC

callahad wrote: post #14

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…

Wow, there are some fantastically stubborn, yet civil minds in that thread. I like Nate's reference to writing a blog post "to help people skip the standard progression of awareness to timing attacks." "Standard progression of awareness" is a wonderful term.

Seriously. Kudos to Nate Lawson for being so patient in explaining the vulnerability he found in the developer's code to the developers themselves.

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

#59

Post by amalcon » Sat, Jul 17, 2010, 3:34 PM UTC

NateLawson wrote: post #46

tptacek wrote: post #42

Earlier quoted context omitted.

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.

This was the one I had in mind.

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

#60

Post by Groxx » Sat, Jul 17, 2010, 7:04 PM UTC

JoeAltmaier wrote: post #57

Groxx wrote: post #16

Earlier quoted context omitted.

That effectively already exists. The internet isn't instant or consistent, and this is about remote timing attacks.

The internet is Statistically consistent, which is all the attack needs.

Even if you added a random up to one second pause, that's still "Statistically consistent", it just requires far more samples to detect millisecond variations.