TGC cookies protection info

[Chris-387]

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
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas

[microcline]

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
> [hidden email]
> http://tp.its.yale.edu/mailman/listinfo/cas
>  

_______________________________________________
Yale CAS mailing list
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas

[Trenton D. Adams]

Hi Guys,

I agree with Andrew.  The only risk is if your service is not using SSL as well.  In cases like that, it is trivial to intercept the cookie, and use it to gain access to the site the user was attempting to gain access to.  But, even this requires a high level of access to networks between the user and the service server.  i.e. Perhaps a disgruntled employee at an ISP somewhere in between.  So, even in the case when not using an SSL enabled service, it is pretty difficult to intercept a ticket.

----- "Andrew Petro" <[hidden email]> wrote:

> 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
> > [hidden email]
> > http://tp.its.yale.edu/mailman/listinfo/cas
> >  
>
> _______________________________________________
> Yale CAS mailing list
> [hidden email]
> http://tp.its.yale.edu/mailman/listinfo/cas

__
    This communication is intended for the use of the recipient to whom it
    is addressed, and may contain confidential, personal, and or privileged
    information. Please contact us immediately if you are not the intended
    recipient of this communication, and do not copy, distribute, or take
    action relying on it. Any communications received in error, or
    subsequent reply, should be deleted or destroyed.
---
_______________________________________________
Yale CAS mailing list
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas

[microcline]

Some javascript/style in this post has been disabled (why?)

Trenton,

You're quite right, it is important that the target service use SSL as well.  It is trivial to intercept the *session cookie* that you will almost certainly establish with that particular service if the service does not use SSL.  It's also trivial to listen in on traffic and even to forge responses in a non-SSL environment.  It's a matter of degree, but I would strongly recommend not relying on the difficulty of intercepting a ticket under a regime of non-SSLed target services as a factor lending security to a system using CAS.

However, I would emphasize: no matter whether the target service uses SSL or not, or anything else it does, or if it's compromised, or if evil people with nefarious intentions wrote it and are running it, or anything else: there's *nothing* that the service to which you're trying to authenticate can do to get access to the Ticket Granting Cookie or primary credentials themselves.  The service ticket for the specific purpose of authenticating to that application can be exposed by a compromised target service, but the compromised target service cannot access the ticket granting cookie and so cannot accomplish authentication to other services i.e. illicit proxies.

Andrew



Trenton D. Adams wrote:

Hi Guys,

I agree with Andrew.  The only risk is if your service is not using SSL as well.  In cases like that, it is trivial to intercept the cookie, and use it to gain access to the site the user was attempting to gain access to.  But, even this requires a high level of access to networks between the user and the service server.  i.e. Perhaps a disgruntled employee at an ISP somewhere in between.  So, even in the case when not using an SSL enabled service, it is pretty difficult to intercept a ticket.

----- "Andrew Petro" [hidden email] wrote:
  

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
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas
  
      

_______________________________________________
Yale CAS mailing list
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas
    

__ 
    This communication is intended for the use of the recipient to whom it
    is addressed, and may contain confidential, personal, and or privileged
    information. Please contact us immediately if you are not the intended
    recipient of this communication, and do not copy, distribute, or take
    action relying on it. Any communications received in error, or
    subsequent reply, should be deleted or destroyed.
---
_______________________________________________
Yale CAS mailing list
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas
  

_______________________________________________
Yale CAS mailing list
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas

[Trenton D. Adams]

Some javascript/style in this post has been disabled (why?)

Absolutely, I totally agree.  It's not a good idea to use non-SSLed services.

----- Original Message -----
From: "Andrew Petro" <[hidden email]>
To: "Yale CAS mailing list" <[hidden email]>
Sent: Friday, February 22, 2008 11:30:35 AM (GMT-0700) America/Denver
Subject: Re: TGC cookies protection info

Trenton,

You're quite right, it is important that the target service use SSL as well.  It is trivial to intercept the *session cookie* that you will almost certainly establish with that particular service if the service does not use SSL.  It's also trivial to listen in on traffic and even to forge responses in a non-SSL environment.  It's a matter of degree, but I would strongly recommend not relying on the difficulty of intercepting a ticket under a regime of non-SSLed target services as a factor lending security to a system using CAS.

However, I would emphasize: no matter whether the target service uses SSL or not, or anything else it does, or if it's compromised, or if evil people with nefarious intentions wrote it and are running it, or anything else: there's *nothing* that the service to which you're trying to authenticate can do to get access to the Ticket Granting Cookie or primary credentials themselves.  The service ticket for the specific purpose of authenticating to that application can be exposed by a compromised target service, but the compromised target service cannot access the ticket granting cookie and so cannot accomplish authentication to other services i.e. illicit proxies.

Andrew



Trenton D. Adams wrote:

Hi Guys,

I agree with Andrew.  The only risk is if your service is not using SSL as well.  In cases like that, it is trivial to intercept the cookie, and use it to gain access to the site the user was attempting to gain access to.  But, even this requires a high level of access to networks between the user and the service server.  i.e. Perhaps a disgruntled employee at an ISP somewhere in between.  So, even in the case when not using an SSL enabled service, it is pretty difficult to intercept a ticket.

----- "Andrew Petro" [hidden email] wrote:
  

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
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas
  
      

_______________________________________________
Yale CAS mailing list
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas
    

__ 
    This communication is intended for the use of the recipient to whom it
    is addressed, and may contain confidential, personal, and or privileged
    information. Please contact us immediately if you are not the intended
    recipient of this communication, and do not copy, distribute, or take
    action relying on it. Any communications received in error, or
    subsequent reply, should be deleted or destroyed.
---
_______________________________________________
Yale CAS mailing list
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas
  

_______________________________________________
Yale CAS mailing list
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas

[Chris-387]

Hi all,

In my initial configuration and test case study, I had completely
disabled the non-SSL access; so all CAS transactions are only done by SSL.

Thank's a lot for all your answers.

Best,

Chris

_______________________________________________
Yale CAS mailing list
[hidden email]
http://tp.its.yale.edu/mailman/listinfo/cas