Dale, Yes, our concern is mostly with dynamically generated ones (i.e. you go to a site that generates them behind the scenes when you think you are just clicking through). The one time use and timeout of service tickets eliminates almost any issue with mass phishing attacks.
These guidelines and recommendations for user interfaces should assist in minimizing any impact the dynamically generated URLs would have (you could potentially only target an individual). Any attack would also require an account within a closed community, whether its your account or a compromised account. That's why non-technical solutions are key. Strong passwords, user education, usability recommendations, account verification, etc. That's what we're hoping to collaboratively build into that wiki page. Cheers, Scott On Thu, Jun 10, 2010 at 11:55 PM, Dale Ogilvie <[email protected]>wrote: > Having a short timeout on the service tickets would mitigate that > vulnerability. Service tickets should really be consumed within seconds of > generation. > > The bad guy would then have to dynamically generate his malicious urls > during his deception of the victim to pull it off successfully. Which would > require a live connection back to his malicious headquarters with his TGT. > > ------------------------------ > *From:* Scott Battaglia [mailto:[email protected]] > *Sent:* Friday, 11 June 2010 2:37 p.m. > *To:* [email protected] > *Cc:* CAS Steering Committee; [email protected] > *Subject:* [cas-user] Announcement: Mitigating the Risk Due to Inherent > Characteristics of Bearer Tokens > > Dear CAS Community, > > The CAS Steering Committee was recently presented with a paper that > detailed some of the risks of protocols that use bearer tokens. The paper > specifically mentioned CAS, though just about all protocols that use bearer > tokens are subject to these risks. > > The Steering Committee has drafted a formal response to this paper and > encourages you to read it (the response specifically, but feel free to read > the paper also!): > > https://wiki.jasig.org/display/CASST/Mitigating+Risk+due+to+the+Inherent+Characteristics+of+Bearer+Tokens > > We've also started a document where the CAS community can collaborate on > best practices for securing their applications (its a bit sparse right now, > but we expect it to grow): > https://wiki.jasig.org/display/CASC/Client+Security+Recommendations > > We encourage you to read and contribute to this document. > > We take security and usability of the CAS Server and Clients seriously. > Future releases of the CAS Server and CAS clients will continue to take a > lead in implementing security and usability best practices in order to > protect users. Look for some of those to appear in the CAS Server 3.5 > release. > > If you have any questions, please do not hesitate to contact the steering > committee. > > Thanks > Scott > -- > Scott Battaglia > Chair, Jasig Central Authentication Service Steering Committee > (sent on behalf of the entire CAS Steering Committee) > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
