21–30 of 61 posts
"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…
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. :)
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?
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
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.
Can someone summarize if (and how) this is different from the timing attack on OAuth from last year that prompted OAuth 1.0a?
"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.
Earlier quoted context omitted.
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.
So then is the fix as simple as removing the early "break;" statement from a strcmp?
Earlier quoted context omitted.
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.
So then is the fix as simple as removing the early "break;" statement from a strcmp?
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.