When verifying a (HMAC) authentication tag it is often indicated that a constant-time comparison is required for security. I can see how leaking information about a password hash can introduce a mild vulnerability as the password hash may become known. However, we're talking here about a calculation over a known and randomized ciphertext.
What would be the vulnerability if we were to perform a non-time constant comparison? Could it be that it would allow recovery of secrets (e.g., passwords) used to derive the authentication key?
Are there other attacks possible if we assume that the derived keys are fully randomized (i.e., no information about the value of the individual bits is known to the attacker?)
Let the vulnerable comparison compare byte-by-byte and break out of the loop after the first mismatch. If we neglect noise, this leaks how many bytes (prefix) of the MAC are correct via timing.
Then attacker could send the same message with the same nonce over and over again, with varying MAC. After an average of 128 tries, one more byte of the MAC will be correct, which will result in the comparison taking longer and the attacker learning it's correct. Then they can lock in that byte, and vary the next byte of the MAC. For a 16 byte MAC it will take 128*16=2048 tries to construct a fully valid MAC which the recipient will accept.
This will not leak the MAC key, but it will produce a successful forgery.
If the recipient accepts multiple messages with the same IV/nonce, the attacker can then combine this attack with any applicable oracle attack against then underlying unauthenticated encryption (e.g. padding-oracle against CBC) to learn the contents of an intercepted message.