Authentication Tokens should use HMAC instead of MAC

We currently use MessageDigest to compute a "SHA" MAC for signing Authentication Tokens. Firstly, what "SHA" maps to is dependent on the JVM and Cryptography Provider. While they should do something reasonable, it's probably a safer idea to pick a specific algorithm. It looks like the Oracle JVM picks SHA-1; though something like SHA-256 would be better.

In any case, it would also be better to use an HMAC algorithm instead.

Changing from SHA-1 to SHA-256 or MAC to HMAC won't generate equivalent signatures, so this would normally be an incompatible change because the server wouldn't accept previous tokens it issued with the older algorithm. However, Authentication Tokens are used as a cheaper shortcut for Kerberos, so it's expected for users to also have Kerberos credentials; in this case, the Authentication Token will be rejected, but it will silently retry using Kerberos, and get an updated token. So this should all be transparent to the user.

And finally, the code where we verify a signature uses a non-constant-time comparison, which could be subject to timing attacks. I believe it would be quite difficult in this case to do so, but we're probably better off using a constant-time comparison.