Use delay with a fixed total time to defend against timing attacks

Question

Consider this common example used to demonstrate timing attacks:

async def sign_in(username, password):
  user = await get_user_from_db(username)
  if user is None:
    return False  # early return :(

  password_hash = slow_hash(password)
  return verify(password_hash, user.password_hash)

The usual suggestion is to do the same thing on all execution branches. For example, something like this:

async def sign_in(username, password):
  user = await get_user_from_db(username)
  if user is None:
    actual_password_hash = "foo"
  else:
    actual_password_hash = user.password_hash

  password_hash = slow_hash(password)
  res = verify(password_hash, actual_password_hash)
  return res and user is not None

But I wonder if the following strategy is also useful against timing attacks (not considering other types of side-channel attacks), while not wasting computing resources:

async def sign_in(username, password):
  # Longer than what `sign_in_impl` takes normally
  fixed_duration = ... 

  _, sign_in_result = await asyncio.gather(delay(fixed_duration), sign_in_impl)

  return sign_in_result

# Awaits a certain amount of time
async def delay(duration):
  ...

# This takes variable time
async def sign_in_impl(username, password):
  user = await get_user_from_db(username)
  if user is None:
    return False  # early return :(

  password_hash = slow_hash(password)
  return verify(password_hash, user.password_hash)

Answer 1

TL;DR

I don't see anything in your provided code that would need to be protected against timing attacks. The purpose of timing attacks is to learn the plaintext secret, but since your code does not handle the plaintext secret (only a hash of it), your code couldn't leak the plaintext password even if it wanted to.

Technically your hash comparison should be constant time, but see below for why I'm not worried about this in practice.

---

Background on timing attacks

Let's take a step back and ask what timing attacks are trying to prevent. With passwords, as with all of crypto, you are trying to exploit timing differences in the function that is handling secret data in order to learn the secret.

The classic example is testing for equality between a stored password and a provided password using lazy string compare:

boolean compare(String str1, String str2)
   for (i=0; i<len(str1); i++)
      if (str1[i] != str2[i]) return false;
   return true;

Here you can learn the password one character at a time because when you get the first character right, the string compare will take slightly longer.

What about hashed passwords?

What if you are comparing password hashes rather than plaintext? In theory, if an attacker learns the first character of the password hash, they have gained information, so that is technically an information leak. However, in practice, a timing attack against hashed passwords would require the attacker to submit password candidates p where they can control hash(p) one character at a time (ie first a*, then aa* ...). This is hard. In fact, finding a plaintext whose hash has a given prefix is exactly the cryptographic problem that keeps bitcoin and blockchain secure, and that's on SHA-256; doing it on PBKDF2 or Argon2 would be even harder.

Does your code need to be constant time?

Given the argument above about handling password hashes, it doesn't really matter if this line is constant-time or not:

return verify(password_hash, user.password_hash)

It also does not matter at all whether this line is constant-time; who cares if they can learn password through a complex side-channel attack, they just submitted it to you, they already know it.

password_hash = slow_hash(password)

IMO it also doesn't matter whether your DB queries are constant time. The attacker would be learning how full your DB is, how much backend network congestion and server load you have, etc, none of which helps them crack passwords. (if your product security model does want to protect info about backend load, that's a much harder and completely separate question).

---

Bonus: adding random delays

While not directly mentioned in your question, I've written before about how adding random timing delays increases the number of statistical samples (ie the number of login attempts) that an attacker needs in order to perform the statistical attack, but it's ultimately not a solution.

• Can I prevent timing attacks with random delays?

Answer 2

Either option would contribute towards mitigating timing attacks. Remember though that some of those methods will take varying amounts of time to complete, specifically the database lookup.

Another way you could contribute towards mitigating timing attacks is to add a random delay(a) to successful login calls(c) and another random delay(b) to failed login calls.

If you make the delay (a) a random(max_jitter_amount) and if you can accurately calculate the average time taken by (c), then your random delay (b) would be something like avg_time(c)+random(max jitter amount). This way every single request will return a certain amount of time + a random jitter amount which would defeat statistical analysis.