Question

It seems that for a while, the login utility on Unix systems only calculated a hash when a valid username existed; this opened a security flaw which allowed for a timing attack, as the user could tell when a username was found by the amount of time it required to generate hashed key for comparison.

This makes sense for desktop applications, but would it make sense for web applications too? I’d lean toward doing it, but is this kind of fix necessary?

For example, in a Django auth module:

class MyBackend(ModelBackend):

    def authenticate(self, email=None, password=None):
        try:
            user = User.objects.get(email=email)
            return user if user.check_password(password) else None
        except User.DoesNotExist:
            User().check_password(password) # is this line necessary?
            return None

Would the additional hash computation make sense for this scenario? If I employ rate-limiting on auth calls, does this decrease the possibility of a timing attack like this?

Answer 1

The original timing attack, the Tenex attack, had nothing to do with hashing — it worked by positioning the password so that it crossed page boundaries leading to a virtual memory cache miss. The attacker could try a series passwords positioned so that only the first character was in the first page, and it would know that the first character matched when verification took long enough for a cache miss to have happened. The attacker could repeat that for each character in the password.

Unless the attacker has control over fine-grained positioning of inputs in memory, no, timing attacks on passwords are not an issue, but any secret checking algo that is super-linear w.r.t. the length of the secret (>= O(length of secret)) might leak information about the password length.

If you are careful to compare all characters in the password regardless of success, then you also defeat the attack:

boolean match = true;
for (int i = 0; i < min(salted_from_db_length, salted_from_user_length); ++i) {
  if (salted_from_db[i] != salted_from_user[i]) {
    match = false;
    //break;  // Stopping early leaks info.
  }
}
match = salted_from_db_length == salted_from_user_length && match;

You should have tests that make sure that compiler optimizations don’t put timing vulnerabilities back into your code.

Note, the term “timing attack” is also used in other contexts, and those can affect web applications. For example when a system clock is used to construct a covert channel between two processes that should not be able to conspire — javascript loaded in two different origins could establish a low bandwidth channel by using an interval to check the time and looping to consume processor or not to communicate a bit.