
Password crack [affecting OAuth and OpenID] could affect millions - chaostheory
http://www.computerworld.com/s/article/9179224/Researchers_Password_crack_could_affect_millions
======
tptacek
Everyone who reads HN is smart enough to simply read the primary source for
this:

[http://lists.openid.net/pipermail/openid-
security/2010-July/...](http://lists.openid.net/pipermail/openid-
security/2010-July/001156.html)

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, sweeping whole codebases to find and eliminate them, you can safely
expect a major news story every year about some horrible pattern of abuse.
Just a few months ago, Thai and Juliano at Netifera broke a bunch of Java web
stacks with CBC padding oracles, another "old-news" crypto attack that was
discovered in the '90s and promptly forgotten.

~~~
callahad
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.

~~~
blasdel
The reply in question: [http://lists.openid.net/pipermail/openid-
security/2010-July/...](http://lists.openid.net/pipermail/openid-
security/2010-July/001186.html)

------
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."

~~~
pvg
_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?

------
edanm
"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 and comparing against a hash? I don't see how software
would be checking passwords one character at a time.

~~~
tptacek
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.

~~~
metachris
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 < a.length; i++) {
            result |= a[i] ^ b[i]
          }
          return result == 0;
      }
    

Code from <http://codahale.com/a-lesson-in-timing-attacks/>

~~~
tptacek
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.

~~~
metachris
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.

------
xinsight
It's amusing that timing attacks work essentially like those often-mocked
Hollywood movies where the computer/hacker cracks the password one character
at a time.

~~~
arihant
:D

------
LiveTheDream
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.

~~~
tptacek
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 reappearing even in code
where they've been eliminated in the past. They're like weeds, or cockroaches,
and require a concerted and decisive effort to eliminate.

It is simply not "old news" that most OpenID implementations made this
mistake, just like it wouldn't be old news if IIS had an exploitable stack
overflow in its HTTP header parsing.

~~~
NateLawson
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.

------
sh1mmer
Can someone summarize if (and how) this is different from the timing attack on
OAuth from last year that prompted OAuth 1.0a?

------
phreeza
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?

~~~
twp
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.

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

~~~
NateLawson
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]

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

~~~
shajith
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/...](http://github.com/openid/ruby-
openid/blob/master/lib/openid/association.rb#L122)

Edit: Was wrong about what could leak.

------
thrill
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

~~~
tptacek
No. Adding noise to a signal increases the amount of filtering and the number
of measurements you need to take. It doesn't eliminate the signals. The
vulnerability is the signal; the fix --- a constant-time HMAC comparison
function --- is to eliminate the signal.

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

~~~
amalcon
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 of time for
all of them.

~~~
NateLawson
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.

