It has nothing to do with passwords and hashes. API keys are not hashed normally. And all kinds of signatures. It's about way you compare strings from params with secret strings
I can think of a couple examples where hashing passwords directly contributes to leaking information recoverable by examining timing (e.g. enumerating django privilege status for a site's users).
Edit: not to say that you should store your password plaintext. Hashing (well, properly using a KDF) isn't a panacea.
I believe it's OK to bail out early if the lengths aren't equal, but otherwise yes, you'd want e.g. 1234 == 1345 to continue to the end even though it's obvious from the second character that they aren't equal.
Bailing early reveals the information that the lengths are different. In most cases the attacker knows the length of the target string and so this test will never pass. You can probably imagine a scenario where the length isn't known and step 1 is to determine the target length.
Everyone who down voted this:
1) I know this would NEVEEERRRRRRR happen, but if there was a website that didn't hash a password, the timing attack would be applicable.
2) It worth mentioning that a timing attack can be frequently foiled if hashing is used on the server side. I.E. Google gives me an API key, stores the hash on there side. I send the API key to Google they hash it and ocmpare the hash to their stored hash.
I think it's crazy how fat fingered people have become with the down vote trigger finger. I think it's 100% crazy to discus the timing attack without considering how it could be thwarted.
