Yes, systems that hash passwords aren't timeable, because attackers can't "propose" a hash that is correct to the first N bytes in order to find byte N + 1.

If you are comparing literal passwords, you may have something more to be concerned about.

For websites yes, but often you want to transmit the hashed value over the network. In that case it might be easier to implement the constant-time comparison.

Python:

  def is_equal(a, b):
      if len(a) != len(b):
          return False
    
      result = 0
      for x, y in zip(a, b):
          result |= x ^ y
      return result == 0

Java:

  public static boolean isEqual(byte[] a, byte[] b) {
      if (a.length != b.length) {
          return false;
      }
    
      int result = 0;
      for (int i = 0; i < a.length; i++) {
        result |= a[i] ^ b[i]
      }
      return result == 0;
  }

Code from http://codahale.com/a-lesson-in-timing-attacks/

It is a bad idea to send hashed passwords over a network. If you need a level of security beyond "passwords on the wire", use TLS.

Yes I fully agree. But sometimes you can't always use SSL/TLS (eg. for performance reasons within games). For certain requests you might want to add a hash for integrity protection and in that case absolutely use constant-time comparisons.

I might be missing something, but wouldn't that code allow to guess the password length because it returns more quickly if the length doesn't match? As far as I can see, the following would give away less information:

  def is_equal(actual, submitted):
      result = 0
      for i in range(0, len(submitted)):
          result |= ord(actual[i % len(actual)]) ^ ord(submitted[i])
      return result == 0 and len(actual) == len(submitted)

"Not timeable" isn't entirely accurate. There are still ways to make use of timing information; they are just not this particular textbook example.

Be more specific about the attack you're thinking of?

Timing leaks about a password hash can eliminate potential guesses from your dictionary, making a combined online/offline attack marginally more powerful. However, it does not directly reveal the password as it would if they were plaintext.

This was the one I had in mind.

I may be wrong on this, but if you know the mechanism by which it's hashed, then there should be nothing stopping you from doing the hashing on your side as well, and timing the hash comparison. So if 'foo' hashes to 'abcdef' and 'bar' hashes to 'ab0012', and it takes longer for 'bar' to be checked than 'foo', that tells you something about the hash it's comparing against. Obviously in the real world this is significantly more difficult as it's tough to generate data that hashes to what you want it to, but I don't see why such an attack wouldn't be possible.

(Of course, this could be completely different than what the parent was thinking about.)