Can string comparison realistically be exploited in a timing attack on a web server?

Question

Suppose you have the following code in Node:

const { token } = req.body
const hash = crypto.createHmac('sha256', SECRET).update(token).digest('hex')
const user = await User.findById(req.session.userId)

if (hash === user.rememberMeHash) {/*...*/}

The string comparison above is deemed vulnerable to a timing attack because it can leak the character position on a mismatch, so the correct way is

// Hashes are already equal in length because the same hash function was used
if (crypto.timingSafeEqual(new Buffer(hash), new Buffer(user.rememberMeHash))

While true in principle, I can't see how this leak is practically possible. To get reliable time measurements, you'd need to

• isolate the code snippet to avoid interference from side effects (request handling, Express routing, DB queries);
• run a large number of empirical tests in a strictly identical environment (same CPU & memory usage, processes, OS);
• have access to a local server instance that has no traffic or intervention from outside.

None of these are realistic in a distributed system, much less to an attacker with no privileged access and no knowledge of the specific hashing algorithms and secret keys employed.

In practice, you will necessarily get varying and inconsistent results when timing any code, particularly one that is just-in-time compiled like JavaScript. This is well understood in algorithm analysis which doesn't directly measure algorithm runtime because these measurements are acutely sensitive to the underlying hardware, software, compiler, language, etc. In this particular case, compared to a database query or a network call (or even script processing when running node binary on a .js file), string comparison takes a minuscule amount of CPU time to process.

Now, also consider that the above code runs across a cluster of servers behind a load balancer. As such, HTTP response times will vary depending on other incoming and ongoing requests (i.e. website traffic), background processes, hosting provider uptime, network fluctuations (e.g. speed drops), use of Tor or a VPN, and hundreds of other factors.

Considering a real-world web server architecture, how can a mere string comparison ever be exploited in a timing attack?

Answer 1

Timing attacks are possible even if response times seem inconsistent, because you can use statistical analysis to filter out a lot of noise in the data. Average values are much more stable than instantaneous values, for example. A fixed delay (like the one introduced by the comparison) will be added to the average, while inconsistent delays (like the ones introduced by the network) will cancel out. Example:

Response times: 17, 20, 1, 15, 62, 35   
Average: 25

Response times (+1 delay): 18, 21, 2, 16, 63, 36
Average: 26

So as you can see the fixed delay is detectable in the average value, and instantaneous spikes don't matter. Finding a stable average value might be difficult though, and it might require a lot of attempts (thousands or even millions of requests). Also the average value might not even be stable enough, and other statistical analysis might be taken into account.

This complexity makes remote timing-attacks impractical in many situations, although research has shown that they are possible within local networks. This means that an attacker might well try to use such timing-attacks once they have broken into your local network, for example. On the other hand, it might be impossible to use the same attack from a remote location, or it might not be worth it at all anyway, depending on several factors like the configuration of the network and your server. A remote attacker will therefore focus on other vulnerabilities to exploit. Also remember that you can avoid this problem by implementing some kind of rate-limiting in your server, banning any potential attacker after too many attempts.