7

I've read that one shouldn't use strncmp(userSuppliedPassword,origPassword,sizeOfArray) (or String.equals in Java) since one can use a timing attack to guess the password. Rather, one should use a secure string comparison function which will take the same amount of time whether the comparison fails or succeeds.

But as the userSuppliedPassword and origPassword should be hashed (and salted), unless one is already doing something stupid, there seems no way to exploit this attack.

So when is this recommendation true?

schroeder
  • 123,438
  • 55
  • 284
  • 319
time
  • 71
  • 2

2 Answers2

8

As you said, when using a string comparison function which hasn't been designed to resist timing attacks, then it can be exploited to guess the string with which you compare.

Comparing unencrypted and unhashed strings will indeed leak the original string, be it a password (either stored in a database or hard-coded), a session ID, an email address or a multi-factor authentication token - meaning this attack is not limited to the common sense of "passwords".

If the strings are encrypted and the encryption function is known to the attacker (with the associated keys), then they could guess the encrypted string, then decrypt it to get the original string.

If the strings are hashed and the hash function is known to the attacker (and the associated salt, if there's any), then guessing the hash will be harder and harder each byte (due to the avalanche effect), making it very hard to guess more than the first bytes of the hash, but that may be enough to bruteforce if your original string has not enough entropy.

This recommendation is true when you're comparing any user-supplied string (either you hash it or not) with any type of sensitive data (see above, I personally consider that any information related to one user is sensitive).

Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65
  • *"then a dedicated attacker could guess the hash"* This is going to be very difficult with most hash functions due to the avalanche effect. It should be just as hard (if not harder) to recover the stored hash through timing than brute forcing the password. – billc.cn Jan 12 '16 at 14:25
  • 1
    @billc.cn Indeed, I missed that point, corrected my anwser. I think you don't need to recover the full hash to attempt bruteforce, though. – Benoit Esnard Jan 12 '16 at 15:04
3

While true in theory, such timing attacks are not particularly relevant in many practical scenarios.

  • It's irrelevant for most kinds of local attack scenarios, because in that case there are usually far better attack vectors.
  • It's irrelevant for most kinds of remote attack scenarios, because changing network latencies cause so much uncertainty that a few microseconds difference in response time are not measureable.

One edge case where timing attacks can matter, is when attacking embedded hardware "black box" systems. For example smart cards or cryptography chipsets.

Philipp
  • 48,867
  • 8
  • 127
  • 157