Comment 38 for bug 1490804

Root cause is the assumption that any tampering with the PKI token would invalidate the token. There are three major fields in the token that are resistant:

1. The message. Any change to the message will be detected due to it not matching the signature.
2. The signature. Any change to the signature and the message will no longer match its signature.
3. The singning info. This checked against the X509 signing cert byte-by-byte. Any change and it won't match.

What I found in testing is that there are other fields that X509 ignores but should not. These include 0 length fields that are place holders for things like the stripped out Certificates.

The other attack now possible is due to there being 2 different PKI token versions. A PKI token could be converted to a PKIZ token, and the signature is still valid. That was not the case when the hashing approach was chosen.

The most common reason for token revocations is logout from the WebUI.

The impact is probably small but consequential; it only affects revoked tokens in the CLI cases. In the webUI case, the tokens are never stored in full except inside the token database. Instead, the WebUI hashes them, and discards the CMS document. Since this is the primary cause of revocations, these tokens are not at risk.

The second most common is password changes. Since these are performed by the end users themselves, the risk here is slight, but not 0.

The most worry some are token revocations for users leaving a project or being disabled altogether. In order for this attack to be viable, the user must have had a valid token prior to the event, and then they could re-enable the token. Since token timeout is a variable, we can;t make any assumptions. We turned the default down to 1 hour, but many sites found this was too short for workflows, and set the value back to 12 hours.