Chris, The ticket granting cookie is typically an SSL-vended, tightly-scoped (just for your CAS server), session-scoped (expired by your browser when your browser session ends) cookie.
I say typically because all these things are configurable, but I strongly recommend you don't change the defaults on any of these aspects of the cookie. There are two perspectives to examine cookie security. One perspective is security on the web. Since the cookie is SSL-vended, the Adversary cannot obtain it by evesdropping on the line. Since it is tightly scoped (and SSL-vended), the browser will not re-present this cookie on requests to sites other than the CAS server. Since the cookie is not used to authenticate to other sites (rather, the cookie is re-presented to CAS, which then issues a shorter-lived transactional service ticket conveyed via request parameter on a redirect rather than as a cookie), other sites do not have access to this cookie. So, "How secure is the TGC?" The TGC is "very secure", in that industry-standard methods for protecting session cookies are applied to protect what is effectively a CAS server session cookie. It is no easier for the Adversary to steal a TGC from the browser over the web than it is to steal any other secure session cookie, such as that you use to access your bank's account management web application during the course of an active session. There's another perspective for considering TGC security -- what if the Adversary has direct access to the end user's computer? What if the computer is compromised, or physically stolen during the course of an active session in which the TGC is still resident? Since it is session-scoped, typical browsers will not commit it to disk and will delete it when a browser session ends normally, so the window of opportunity is narrow. Nonetheless, the popular expression among computer security professionals goes something like "physical access to the computer is equivalent to root access", and that is apt here. A compromised web browser, operating system, or physically accessed machine can have spyware installed, a compromised browser installed, to capture the primary credentials when they are presented to CAS, to capture TGCs, or really to do anything else. Compromised computers are a bad thing. CAS makes this no worse, but it doesn't magically solve it. To put this in perspective, if I access my online bank account web interface from a compromised computer, I necessarily reveal all the credentials necessary to access my account from that computer, at least for the course of that session. If one were inclined to implement all those fun rotating security questions, distinctions between public and personal computers, IP address tracking to prevent cookies from being presented from different IP addresses during the course of a session (personally, I truly despise this misfeature), while CAS doesn't tend to have these features out of the box, it certainly offers an extensible platform in which they can be implemented. Spring Web Flow for the win. Andrew > Hi, > > I've successfully installed and configure CAS to use my LDAP user > database. I'm almost on production stage :) > > My IT asked me about "How secure is the TGC?" meaning is it possible for > a hacker to steal a TGC from a user browser, and use it to impersonate a > user. > > I read in the doc and powerpoints that the TGC was 'private' and > 'protected' but I dunno exactely what it means. > > Can anyone tell me more about TGC protection? How much are they secured? > > Best, > > Chris > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
