OAuth, OpenID Password Crack Could Affect Millions

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

Comments

Who doesn't hash/encrypt passwords?

[MankyD]

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

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?

Re:Who doesn't hash/encrypt passwords?

[betterunixthanunix]

You'd be surprised. Salting and hashing passwords seems like common practice, but most programmers have minimal security training (yes, even those programmers who implement password based authentication systems) and may fail to realize the significance of not hashing.

Now, the fact that open source projects have this problem is a bit disturbing...

Or do not have variable delays at all

[betterunixthanunix]

This is neither a new problem nor an unsolved problem. This problem stems from using functions like strcmp, which return as soon as a difference is detected, and are thus unsuitable for password checks. Solution? Set a flag when the first difference is found, and continue checking subsequent characters.

Re:Or do not have variable delays at all

[Anonymous Coward]

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:Or do not have variable delays at all

[Anonymous Coward]

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.

Re:Or do not have variable delays at all

[kyrio]

It's you who is sounding like a troll. The AC is correct, you are not.

Re:Add a random delay

[Enleth]

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.

Doesn't MD5 make this hard?

[tthomas48]

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

[AnonymousClown]

The movie makes me hard....Halle Berry topless and the thought of some hot blond giving a bj while working at the computer.....

Suspension of disbelief, dude.

Seriously?

[FranTaylor]

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:Seriously?

[disambiguated]

Compiler-optimized code on a 64 bit machine compares 8-bit characters 8 at a time. This guy is trying to force a context switch (upwards of thousands of instructions) to save 4 or 5 instructions. It doesn't save CPU (because of the context switch), it increases the latency, it's harder to code, and may be still vulnerable! sweet.

Re:Add a random delay

[Anonymous Coward]

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

[droidix55]

Say you have two hashes

1. break each into an array of integers, create a result array with the same size
2. XOR the two arrays containing the hashes into the result array
3. OR all of the ints in the result array together
4. if the result is 0 then the authentication is successful

Would that work?

Re:Add a random delay

[clone53421]

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

[Ant P.]

So in your system, I could lock you out of the site simply by doing a bad login on your username three times? Nice.