Reason for variable time verification?

[Ivoz]

Is there a particular reason that a token is not verified for integrity before its timestamp is checked?

This allows attackers to discover the decrypter's valid TTL, by monitoring how long they take to verify a message.

So you have constant-time verification of valid tokens, but variable time verification of invalid tokens.

Additionally, is there a reason the spec transmits the timestamp in the clear, rather than encrypted? Surely doing the latter would make it useful to more people; and any applications or user contexts which relied on a message's send-time being private might also currently mistakenly use this protocol.

I assume time to verify a HMAC is not a problem, since tokens are url-safe base64 encoded - either short enough to be present in a url, or not long enough to worry about the storage inefficiency of base64.

[dolph]

This is definitely true, but I imagine the answer is "performance versus security," on both counts. Having the timestamp in plaintext allows anyone who don't have the keys to verify the token's integrity or to decrypt the payload to verify that the token is not completely out of date.

For example, to take your concern to the extreme, you can validate that the timestamp is within some TTL near the edge of your infrastructure, and save yourself from the additional overhead of handling the request any further.

If there's potential for exploit here, I'd be curious to hear about it, but I'm struggling to think of anything alarming. At worst, perhaps a malicious user manipulates the plaintext timestamp and forces the HMAC validation to occur, but that's not much of a DoS, because as you pointed out, the time to verify an HMAC is not really a problem.