You assume that boolean operations are constant time, and whether that holds depends on the uarchitecture and how sophisticated the optimization layers are (e.g. nothing prevents the compiler or even the CPU from short-circuiting the OR as soon as the first XOR is non-zero).

Computing a MAC of the two input values under a once-off random key is actually much stronger.

As a matter of that, this highlights that the goal is to lower the SNR for the attacker, and constant time computation is only one of the two non-exclusive ways to achieve that, the other being adding sufficient noise to their measurements.

If you check hash(a) == hash(b), the attacker cannot produce a valid hash, because cryptographic hash functions are one way. This assumes you use a secure hash function, like not md5.

Even if they discover hash(b), they can't produce b.

Yeah, I (but I am not not OP) agree that hashing is not absolutely perfect, but it's still much much better than leaking the actual password, and it would be cool to at least compare it as a feasible solution.

Getting the first character of the hash is trivial, but as you get further and further out you need to do more and more computational work locally to guess a string which will hash to the prefix you already know (given that your hash is secure against Preimage attack). And then at the end you end up with the complete hash, which itself is extremely hard to get anything useful out of. (all of this is given that you use a hash that is resistant to Preimage attack, and preferably salting as well).

Basically you can figure out the hash using the aforementioned timing attack.

You can now perform an offline attack against the password that produced the hash.

It’s like you hacked into the database and got the password hashes.

Then, you fall back to something like hashcat.

If with a bit of luck you just hashed your password with a single round of SHA and did not use something cool like Argon2id then you’re toast. If your password is simple you’re toast too.

On the other hand, if you hashed a totally random key, the safety will rely on whether the hashing algorithm itself is constant time or not. You just moved the needle.

> What's the difference between a plaintext key and a hash in this context?

> The attacker can crack the first byte of the key by trying all 256 possibilities, and observing which one caused the comparison to take longer.

OK as a thought experiment, the algorithm is passed plaintext data A (the input that the hacker is trying to guess) and hashed data B.

It hashes A before starting a comparison and then does a naive check, an we have code like-

  function checkApiKey(inputKey, correctHashedKey) {
    inputHashedKey=sha256(inputKey)
    if (inputHashedKey !== correctHashedKey) {
      throw new Error("wrong key");
    }
  }

If we're using a decently secure hash algorithm, for every bit that changes in the input, we will create (indistinguishable from) random changes throughout the output. An attacker on this system can't just continually tweak the first byte of input to figure out when a longer comparison takes place, because there's no guarantee that doing that will ever result in the first byte of the hash matching the first byte of the stored hash. And in theory that doesn't actually give away any information about the full password, because if you've matched byte one, adding the next byte to your guess changes the whole hash in unpredictable ways.

Constant time still removes this sort of avenue entirely, but this would seem to confound the attack (or at least make it much harder problem to solve).

Happy to be educated otherwise if someone that's actually an expert would like to chime in?

You could use a non-constant salt for the hash, for instance use a sufficiently random number or start with one and increment it, so the comparison is hash(input+salt)==hash(secret+salt), that way each attempt gets the attacker at best a part of a different hash.

This is also assuming the secret is know in plain text – for properly stored passwords you now have hash2(hash1(input+salt1)+salt2)==hash2(prehashed-secret+salt2) with salt2 changing on each attempt.

Of course this is a more computationally expensive than a more direct time-invariant string compare such as bitwise-xor-secret-with-guess-then-bitwise-or-all-bytes-in-result-and-compare-that-to-0, so messing around with hashes & salts is probably not what you would do. The XOR-the-OR method isn't perfect, it will still at least leak the length of the secret if it is unhashed (hashing just before the comparison won't save this because the hashing itself is not time invariant).

You can use a hash where the supplier of inputKey is not able to know the hash value. E.g.,

  function checkApiKey(inputKey, correctKey) {

    r = randomString()
    inputHash = hash(r + inputKey)
    correctHash = hash(r + correctKey)
    
    if (inputHash !== correctHash) {
      throw new Error("wrong key");
    }
  }