I'll make one more attempt. I don't think I can explain it any clearer than this:
http://pastebin.com/MYT9kpgZ
Here I model the server as a simple function that takes a password, hashes it, and compares it to a known digest with an '==' substitute. The function returns true or false, but also leaks information about how long the match was, through a simulated timing leak.
This lets me identify the dictionary word that was used as a password using just 23 login attempts, instead of the expected 19300 from a brute force attack.
In effect, you're giving the attacker the ability to perform an almost offline attack, as if they possessed the password hash, by supplying however much of the hash they need.
I don't see how this would not be a security problem, if you acknowledge that testing a HMAC with == is.
Again, this is trivially preventable by using a timing independent comparison.
http://pastebin.com/MYT9kpgZ
Here I model the server as a simple function that takes a password, hashes it, and compares it to a known digest with an '==' substitute. The function returns true or false, but also leaks information about how long the match was, through a simulated timing leak.
This lets me identify the dictionary word that was used as a password using just 23 login attempts, instead of the expected 19300 from a brute force attack.
In effect, you're giving the attacker the ability to perform an almost offline attack, as if they possessed the password hash, by supplying however much of the hash they need.
I don't see how this would not be a security problem, if you acknowledge that testing a HMAC with == is.
Again, this is trivially preventable by using a timing independent comparison.