Actually, we did consider security implications of posting directly from the remote site to the CAS server. This approach theoretically opens up additional risk for phishing attacks, but actually most users would be just as susceptible to phishing attacks when the standard CAS redirect protocol is used. For example, how often do you REALLY double-check the URL in your browser's address bar when you're logging into your own CAS implementation? I know I personally don't check it very often. (For that matter, I trust that "www.gmail.com" will correctly redirect me to "google.com/accounts" and I almost never check the address bar on Google.) Avoiding phishing is all about user training, and users can probably be trained to recognize phishing in context of this technique as effectively as they could with respect to the standard CAS redirect implementation.
The most "real" additional risk, I think, is the risk of replay attacks because the "lt" parameter is not included. We are currently only using this technique with a single site for a proof-of-concept, so we will be considering ways to mitigate the risk of replay as we look towards the possibility of more widespread use. One option is to use a REST API to fetch a login ticket, possibly with JavaScript using cross-domain AJAX techniques to fetch the login ticket right before the form is submitted. Another possibility is to use a timestamp instead of "lt", and putting a narrow validity window around the timestamp. While I have considered a number of scenarios and identified these two risks, I would be interested in hearing if others can uncover additional ways that this technique would introduce additional security risks. -Nathan -----Original Message----- From: Michael Ströder [mailto:[email protected]] Sent: Wednesday, March 04, 2009 7:59 PM To: [email protected] Subject: Re: [cas-user] How to use custom login page instead of CAS login page? Nathan Kopp wrote: > > To accomplish this, we use a technique where the login form is served by > the client web site and simply posts the username and password directly > to the CAS server along with the “service” parameter. Hmm, one should think about some security implications of such an approach... Ciao, Michael. -- 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
