Password crack [affecting OAuth and OpenID] could affect millions
computerworld.com
Password crack [affecting OAuth and OpenID] could affect millions
1–10 of 61 posts
Re: Password crack [affecting OAuth and OpenID] could affect millions
#2if 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
Re: Password crack [affecting OAuth and OpenID] could affect millions
#3if 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
"For every problem there is always a solution
that is simple, obvious, and wrong." -- Mark Twain
As I say, I'm not an expert, but if you google this it should give you references to papers that discuss the issues.
Re: Password crack [affecting OAuth and OpenID] could affect millions
#4if 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
[deleted]
Re: Password crack [affecting OAuth and OpenID] could affect millions
#5if 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
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.
Re: Password crack [affecting OAuth and OpenID] could affect millions
#6This 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.
Re: Password crack [affecting OAuth and OpenID] could affect millions
#7if 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
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.
Re: Password crack [affecting OAuth and OpenID] could affect millions
#8This 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 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.
Re: Password crack [affecting OAuth and OpenID] could affect millions
#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 and comparing against a hash? I don't see how software would be checking passwords one character at a time.
Re: Password crack [affecting OAuth and OpenID] could affect millions
#10Everyone 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, 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.