3

I am not very familiar with security stuff, but have encountered this constant time function to prevent timing attacks:

// shortcutting on type is necessary for correctness
if (!Buffer.isBuffer(a) || !Buffer.isBuffer(b)) {
  return false;
}

// buffer sizes should be well-known information, so despite this
// shortcutting, it doesn't leak any information about the *contents* of the
// buffers.
if (a.length !== b.length) {
  return false;
}

var c = 0;
for (var i = 0; i < a.length; i++) {
  /*jshint bitwise:false */
  c |= a[i] ^ b[i]; // XOR
}
return c === 0;

https://github.com/salesforce/buffer-equal-constant-time/blob/master/index.js

Wondering if there are standard things to watch out for, and techniques like the above to solve them, when considering timing attacks. Something like OWASP's XSS Cheat Sheet. Thank you!

Lance
  • 75,200
  • 93
  • 289
  • 503

2 Answers2

3

One of the biggest things you can do to protect against timing attacks is to use proper cryptographic libraries and the helper functions they provide (for example, if you're using the bcrypt.js library, use the compare function that it provides, rather than doing your own string comparisons). Any time you try and implement your own crypto it's probably going to be vulnerable to timings attacks.

These kind of attacks can be very hard to perform though - there are (normally) very small differences in the time to compare strings, for example, which would be harder to detect over the internet (although you can work around this with large samples).

The attacks that are easier to exploit are often where there's some kind of external interaction from your code. For example, a password reset feature might have to send an email (which can be slow) if the username is valid, and may just return immediately if it's not. Asynchronous external calls can help here (and are probably better for the user anyway).

Most timing attacks rely on an attacker being able to make a large number of scripted requests and analyse the response times, so anything you can do to make this harder (for example, rate limiting or a CAPTCHA) will also provide you a degree of protection. It doesn't necessarily solve them, but it would make them harder to pull off.

Realistically, unless you're doing something crypto related, there are probably bigger threats to worry about.


Edit: A few years after making this post, the Bcrypt.js developers discovered that their timing-safe string comparison function actually wasn't. In the context they're using it (comparing hashes) it's not an exploitable issue, but it shouldn't be used for anything where timing attacks are a concern.

rbsec
  • 131
  • 4
  • 1
    the `bcrypt` library [explicitly warns](https://www.npmjs.com/package/bcrypt) that its comparison function is not immune to timing attack and users are expected to handle it themselves – Alex May 21 '21 at 19:57
  • Just to clarify, the comparison function does not need to be timing attack safe because bcrypt and other hashes are inherently immune to timing attacks. If a single character of the input is changed, the output is wildly different. Meaning you can't tweak the input to incrementally get an output closer to the correct hash. This is called the avalanche effect. – Liz Feb 14 '23 at 13:42
0

While your implementation should be timing safe (next to leaking the correct length, however this might be irrelevant depending on the context) - a pitfall still exists: optimization.

This may happen at compile time (i.e. C/++/#) or in the case of java just in time or during runtime through the JVM. Optimization can unfortunately (re)introducing timing side channels - thus, I strongly suggest that you rely on proven crypto libraries / functions, such as hash_equals for PHP or MessageDigest.isEqual for Java (after Java SE 6 U17).

Generally speaking, not only string comparisons can lead to timing attacks. Many other operations can lead to differences in response / execution time.

If you are interested in further examples of timing attacks and their possible mitigations, please refer to: https://zgheb.com/i?v=blog&pl=81#05.11.2021_-_When_timing_matters

Note: I am the author of said blog.

ozzi-
  • 159
  • 2
  • 12