I recently came across some password code that hashed the password and then compared it with the saved hash in the naive way: one character at a time, short-circuiting as soon as a non-match was found. We agreed it was a security bug and fixed it.
However, this code piqued my curiosity: suppose an attacker is able to glean from the timing of password checking the number of hash digits that match. How could this bug be exploited in practice? I understand security should be deep and you need not find a practical exploit to take a security measure - I'm asking purely out of curiosity.
For example, the attacker might try progressively extending the hash one character at a time. But if the hash is n digits long, the attacker eventually needs to extend from n-1 digits to n digits. Assuming a good hash function, this seems to require a full pre-image attack. Assuming the attacker can compute the hash, which requires the attacker to have the salt if there is one, this attack could largely be performed client-side (given n digits in base b, a maximum of n*b queries to the server are required). But hash functions are chosen to resist pre-image attacks so is this exploit practical?