Real Security vs. Excessively Clever Tricks

Someone asked off-list:

Has there ever been any thought to add additional checks to guard against rogue Ticket Granting Cookies? This thread got me thinking that CAS server could record and check the TGC against the IP address, User Agent, etc that is as issued to. Not sure this would actually add anything...thoughts?

I'm very reluctant to add additional checks for Ticket Granting Cookie validity in CAS. None of them would actually improve security, and all of them would make CAS less convenient or more fragile. I'd suggest that adding these tricks can only hurt - it makes CAS more complicated and provides opportunities to overlook the things that are very important to its security.

One of the beauties of CAS is how little there is in it that doesn't need to be there.

Either we trust SSL or we don't. If SSL fails all bets are off, the Adversary will have your passwords and session identifiers and is home free. Either we trust the end user to supply a non-compromised web browser and machine, or we don't. If the end user types her password into a compromised machine, if she uses a x509 cert on a compromized machine, then all bets are off. The Adversary has primary credentials and is home free.

Security is about the tickets being large random numbers and about not letting the Adversary get at them in the first place.

This connects back to a discussion from some time ago about whether the expected "service" should be included in CAS's ticket validation error response to help application developers to debug.

CAS is not secure because the Adversary can't guess the service identifer: he can. The namespace is too small. CAS is secure because the Adversary cannot acquire or guess a valid Service Ticket [1]. Failing to report the correct service identifier when a service ticket fails to be validated because the service identifier doesn't match doesn't add anything to CAS's security and only misses an opportunity to provide a more useful error response. It doesn't add anything to the security because guessing service identifiers is a formally easier problem than guessing service ticket strings.

CAS is not secure because the Adversary cannot guess the user-agent, can't fake out remote address headers, etc. He might be able to do all those things too; the namespace is too small.

CAS is secure because the Adversary can neither acquire nor guess a valid TGC string in the first place. If that's not true, then CAS is not secure, and no amount of IP address checks, User Agent matches, or any other tricks will help, since an Adversary that can acquire a TGC can with significantly less difficulty guess all those things and fake out all those tricks.

We do not seek to merely inconvenience the Adversary. We don't want to throw minor roadblocks in his path, make him guess service identifiers, IP addresses, user agents, anything like that. We want to shut him out completely. So CAS uses random numbers drawn from large namespaces and SSL. Defeauting CAS is formally equivalent tomsolving any of several hard problems: defeating SSL, hacking the CAS server box, or defeating the SecureRandom random number generator.[2] These are the hardest problems we have available. Adding easier problems for the Adversary to also solve won't make CAS any more secure.

[1]: An application can choose to insecurely receive its service ticket at an http:// URL, and in doing so accepts the risk that the Adversary will intercept the ticket and thereby illicitly access the application, just as it accepts the risk that the Adversary will steal the session on any subsequent request since session cookies and the like are also being sent in the clear. But it is a per-application risk that doesn't compromise the secure session as regards accessing other applications.

[2]: Of course, the Adversary can compromise individual end user machines to get individual end user credentials.