OAuth, OpenID Password Crack Could Affect Millions 304
CWmike writes "Researchers Nate Lawson and Taylor Nelson say they've discovered a basic security flaw that affects dozens of open-source software libraries — including those used by software that implements the OAuth and OpenID standards — that are used to check passwords and user names when people log into websites such as Twitter and Digg. By trying to log in again and again, cycling through characters and measuring the time it takes for the computer to respond, hackers can ultimately figure out the correct passwords. This may all sound very theoretical, but timing attacks can actually succeed in the real world. Three years ago, one was used to hack Microsoft's Xbox 360 gaming system, and people who build smart cards have added timing attack protection for years. The researchers plan to discuss their attacks at the Black Hat conference later this month in Las Vegas."
Who doesn't hash/encrypt passwords? (Score:5, Insightful)
If you do almost any sort of reasonable hashing or encryption algorthm on a password, this becomes a moot point, since the place that fails to match in the string will change. Are there still sites out there that don't do this? Really?
Or do not have variable delays at all (Score:4, Insightful)
Re:Add a random delay (Score:5, Insightful)
No, a random delay just makes it harder for an attacker to determine the nect correct character. The exact theory behind eliminating the random factor eludes me, but several smart people found a way and it's supposedly correct.
I think the proper way is to "pad" the time so that it's constant. Say, if the password checking algorithm can take from 50us up to 600us, pad it to 1500us (safety margin!) with as much precision as posiible. There might be other code paths to pad, too, such as the one that fires when there's not even such a user, but you still want to display the "wrong password" message, as some systems do.
Re:Or do not have variable delays at all (Score:2, Insightful)
Which is just a waste of CPU resources. It's better to use the function that returns immediately, and sleep briefly instead. At least then you're freeing up the CPU for other processes that may have real work to do.
I know, I know, you'll say it's "not a big deal", but you probably just don't deal with real servers that experience heavy load.
Re:Who doesn't hash/encrypt passwords? (Score:3, Insightful)
Now, the fact that open source projects have this problem is a bit disturbing...
Doesn't MD5 make this hard? (Score:3, Insightful)
I hate this kind of announcement because it usually ends up that they found a hack in a revesion Bozo's poorly constructed library from 5 years ago, but I like this kind of announcement because it makes me consider my security.
I'm using a PHP OpenID library that's using md5 for comparison in the database. I don't really see how that would be feasible, since even if you were cycling through characters you need all characters to make the hash which mysql is making its string comparison based on.
Or am I missing something?
Re:lolswordfish (Score:1, Insightful)
Suspension of disbelief, dude.
Re:Or do not have variable delays at all (Score:4, Insightful)
Absolutely not. There is valuable computation done when hashing passwords. There isn't when you continue comparing passwords well after you know they don't match, when you could just as easily yield the CPU to other processes.
You've been proved wrong. Try to argue the point next time, rather than throwing up strawmen.
Seriously? (Score:4, Insightful)
Are you serious?
In the course of an entire web session's worth of CPU consumption, you are worried about the time taken to compare password characters? Any modern optimized processor should require one clock cycle per character.
Do you actually profile your code or do you just make funny noises? Or maybe you're running your web server on a Commodore 64?
Re:Or do not have variable delays at all (Score:3, Insightful)
It's you who is sounding like a troll. The AC is correct, you are not.
Re:Seriously? (Score:4, Insightful)
Re:Add a random delay (Score:1, Insightful)
Yes, you're going to run each password a bunch of times and average them. Are you completely stupid or what? The average of random data converges to a fixed value. Adding random noise to the same value over and over merely biases the average by the average of the random noise over time.
Open any image in GIMP. Add random RGB noise. Be generous, go for uncorrelated independent RGB at 1.0 (i.e. ±255) on all three channels. Save the picture as noise-1.png.
Open original image and repeat. Save it as noise-2.png. Repeat through noise-5.png.
Now average them: Open noise-1.png. Then open as layers noise-2.png through noise-5.png. Set the opacity on the 2nd bottommost layer to 50%, next up 33.3%, 25%, 20%. Observe.
The result will much better resemble the original image than any one of the noisy image did. You absolutely did not destroy the signal (image), you just added noise to it.
So a secure comparison algorithm would be.. (Score:2, Insightful)
Would that work?
Re:Add a random delay (Score:3, Insightful)
GODDAMN. You really ARE that stupid.
We are NOT fucking talking about a SINGLE measurement of time.
We are talking about hundreds - possibly thousands - of "value", plus your random number. Guess what. Your stupid random number averages out to its median over about 1000 attempts. Meanwhile the CONSTANT value remains CONSTANT and as only the RELATIVE position of the values was important, we can compare it to OTHER attempts and determine which was faster REGARDLESS of your stupid random number.
You average it out.
No, I do not expect you to understand that any more than you understood the more helpful (and less insulting) version. You are an idiot.
Re:Answer to brute force attacks (Score:3, Insightful)
So in your system, I could lock you out of the site simply by doing a bad login on your username three times? Nice.