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

31–40 of 61 posts

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

#31

Post by [deleted] »

steveitis wrote: post #12
ronnier wrote: post #5

Earlier quoted context omitted.

On the second page of the article: >Program the system to take the same amount of time to return both correct and incorrect passwords. This can be done in about six lines of code, Lawson said.

Only by introducing a delay where is none is needed. This makes things slower for the rest of us. 1 extra millisecond per user * 8 billion users * times 10 logins a day == Lots Of Lost Man Hours, probably enough to rebuild the great pyramids of Egypt by hand every year. Security researchers are the reason we can't have nice things. :)

[deleted]

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

#32

Post by SoftwareMaven »

twp wrote: post #23
phreeza wrote: post #18

Does anyone know how feasible this kind of attack is with real world network latency and server load fluctuations? In the end it comes down to statistics, but i could imagine forging a token this way might take a very high number of failed attempts, which might then trigger other security mechanisms?

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.

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

#33

Post by shajith »

meeee wrote: post #20

Why should this affect OAuth? The authentication mechanism is not part of the protocol. OpenID is for authentication and OAuth for authorization.

The original post to the mailing list mentions the ruby open-id library (along with Java and Python libraries) as being vulnerable.

Checking out the code, it looks like the string comparison at the end of the check_message_signature method will leak timing info (uses rb_str_cmp internally?).

Link: http://github.com/openid/ruby-openid/blob/master/lib/openid/...

Edit: Was wrong about what could leak.

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

#34

Post by shajith »

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

Nate Lawson debunked this and other arguments in a blog entry linked in the thread:

http://rdist.root.org/2010/01/07/timing-independent-array-co...

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

#35

Post by metachris »

tptacek wrote: post #11
edanm wrote: post #9

"On some login systems, the computer will check password characters one at a time, and kick back a "login failed" message as soon as it spots a bad character in the password. This means a computer returns a completely bad login attempt a tiny bit faster than a login where the first character in the password is correct." This doesn't sound right to me. Aren't passwords usually checked by hashing the entire password an…

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 = 0; i
Code from http://codahale.com/a-lesson-in-timing-attacks/

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

#36

Post by gmonroe »

tptacek wrote: post #13
steveitis wrote: post #12

Earlier quoted context omitted.

Only by introducing a delay where is none is needed. This makes things slower for the rest of us. 1 extra millisecond per user * 8 billion users * times 10 logins a day == Lots Of Lost Man Hours, probably enough to rebuild the great pyramids of Egypt by hand every year. Security researchers are the reason we can't have nice things. :)

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.

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

#37

Post by metachris »

phreeza wrote: post #18

Does anyone know how feasible this kind of attack is with real world network latency and server load fluctuations? In the end it comes down to statistics, but i could imagine forging a token this way might take a very high number of failed attempts, which might then trigger other security mechanisms?

"We have shown that, even though the Internet induces significant timing jitter, we can reliably distinguish remote timing differences as low as 20µs. A LAN environment has lower timing jitter, allowing us to reliably distinguish remote timing differences as small as 100ns (possibly even smaller). These precise timing differences can be distinguished with only hundreds or possibly thousands of measurements."

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

Inside Amazon datacenters you also have lan-like performance.

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

#38

Post by euroclydon »

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…

"if IIS had an exploitable stack overflow in its HTTP header parsing"

Where'd that come from? That's a very interesting example to pull out of your hat.

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

#39

Post by mukyu »

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…

Another example you can cite is people using strcmp to compare digests. I believe this was found an fixed in Netscape and then later shows up again in other SSL libraries and even the Wii's signing a decade later.
Post reply on HN