Hacker News Reader

Comment by ars | Hacker News Reader

> can only be obtained by using hand written assembly or hardware

Even that is harder than it looks.

For example, a common way of doing a constant time string compare is:

    $result |= (ord($safe[$i % $safeLen]) ^ ord($user[$i]));

i.e. get the character to compare mod the length, so you wrap around if the length of the two strings is not the same.

Unfortunately the mod operator does not take a constant time on a CPU! If the result is evenly divisible it's faster.

So even in assembly you might not be able to protect from a timing attack. Even if you check your current CPU a new one might be different.

(In this case a better way to do the compare is if the strings are not the same length, compare the attackers string against itself, and then return false.)

View on HN

For this case, could one just introduce another mod operation which produces result + 1? In this case:

    ($i + 1) % $safeLen

Even so, I guess the only way to eliminate timing attacks would be to write a set of primitive operations (XOR, AND, OR, ORD,...) which are constant-time (on the supported hardware platform) and only use those wherever the private information is handled. Is this possible to do? Are there any attempts at this?

(In this case a better way to do the compare is if the strings are not the same length, compare the attackers string against itself, and then return false.)

Is there a reason for using the attacker's string rather than the valid string? Edit: it doesn't seem to me that using the valid string would leak its length unless the attacker knew quite a lot about the target machine.

> Edit: it doesn't seem to me that using the valid string would leak its length unless the attacker knew quite a lot about the target machine.

It sounds like you are skeptical that timing attacks can be practically exploited. This is a reasonable skepticism that most people go through on initially learning about them. Unfortunately, there are in fact working exploits for this sort of thing.

No, I definitely realize the seriousness of timing attacks. I'm just curious about this particular implementation detail. I would have guessed that using the attacker's length would reveal more about the system than using a fixed length (unless the length of the valid string changed frequently). I'd like to understand why that isn't the case.

Ah, I see, you're assuming the "valid" string is fixed-width across all requests. I guess in that specific case you might be right. But it's easy for that not to be the case: e.g. if there are several different resources an attacker can request that have different-length strings. For example, an attacker might scan for users with short (=bad) passwords by comparing the time it takes to complete an authentication check against various users. So the safe thing to go is to go with the attacker's string.

How long it takes to do the comparison reveals the length of the string being checked, so you have to check the string which the attacker knows the length of already.

Question: if you know the attacker doesn't have local access, is it sufficient to simply introduce random response delays to mitigate JVM-JIT level timing differences? Even if you only delayed responses by a few hundred micros on average (with randomness), I imagine all but the smallest amount of fast-path/slow-path entropy would be lost in the noise.

It requires the attacker to acquire more data - perhaps so much data that the attack is not feasible - but it doesn't rule out a timing attack.

It's pretty easy to filter out the randomness using statistics.

As I understand it, the correct thing to do is to derive a sleep time from hashing the request content, along with some secret. This makes the delay "random" from the attackers point of view, but still deterministic and therefore impossible to filter out.

Note: I am not a security person, just an interested bystander. Take this half-remembered advice with a pinch of salt.

That won't work if there's an irrelevant parameter in the request that can be varied. Say spaces ignored somewhere or additional parameters ignored, for instance.

What is an actual attack scenario where leaking string length mattered?

If you know the length of a user's password, it narrows the search space considerably.

1. Please don't store raw passwords and compare them with strcmp().

2. Less than you'd think. e.g., the total count of all 1 and 2 and 3 digit numbers is only 11% of the count of 4 digit numbers. (And that stat gets worse with just lower case letters.) Searching all shorter passwords ends up being an insignificant amount of time compared to searching all correctly sized passwords.

I agree. Perhaps there's a more practical example?

Reply on news.ycombinator.com