Thanks so much for all of the discussion. It is very helpful. OK, I've looked at the code harder, and I think I understand what Scott is saying now. I was making assumptions about the implementation that aren't true (and I think Martin was making the same assumptions). I do think there is a serious problem with this implementation, though, that violates the CAS protocol section 3.5 on Login Tickets (http://www.jasig.org/cas/protocol). This is strongly related to the other thread I started yesterday titled "CAS login ticket accepted multiple times". I believe that the current CAS implementation is failing this test:
- Login tickets MUST only be valid for one authentication attempt. Whether or not authentication was successful, CAS MUST then invalidate the login ticket, causing all future authentication attempts with that instance of that login ticket to fail. I was assuming that the entire login ticket--the uuid and the SWF id's were being validated by CAS. This appears *not* to be the case. This is what I was missing, and why Scott and I were talking past each other. Rather, CAS is simply prepending a random uuid to the Spring Web Flow id's before encrypting. When decrypting, CAS just decrypts the login ticket, and ignores the uuid--no validation of the uuid is done. This does make the login tickets unguessable, but I don't think that's good enough. It appears that this means that even with the new encryption added to the 3.4.7 CAS release, a CAS login ticket can be used multiple times. It turns out that the Spring Web Flow execution and snapshot id's appear to both start at the value of 1 when a new session is started. At each successful login attempt for a given session, the execution id is incremented by 1 and the snapshot id is reset to 1. At each failed login attempt for a given session, the execution id stays the same, but the snapshot id is incremented by 1. Here is how we can guess a login ticket for the first attempt at logging into the CAS server: 1. Start a browser, clear cookies, and navigate to the cas login page. 2. View the page source and find the hidden input with the name "lt" for login ticket. That's it. I believe that I now have a login ticket that can be used as many times as I want for the first attempt to login to the CAS server in any given session (CAS JSESSIONID) for any user. I know that this ticket has embedded in it the values of 1 and 1 for the SWF execution and snapshot ids, respectively. Since the CAS server completely ignores the uuid value, this ticket is valid for all first attempts to login to the CAS server for a given session. I can easily create a table of CAS login tickets that will work for common cases (where the execution and snapshot ids are small) by just successfully and unsuccessfully logging in a number of times and noting the returned login tickets in the login page html in each case. So, in that sense, CAS login tickets, even with the new encryption scheme, are still "easily guessed", and could potentially be embedded in, scripts. This analysis would appear to be backed up by my experimental observations in the "CAS login ticket accepted multiple times" thread from yesterday. (If you read it, remember that I didn't really have a theory for why my observations were happening the way they were at that time). If my analysis is correct, it would mean that the symmetric key solution doesn't satisfy the protocol requirements for a login ticket that can't be reused and should therefore be corrected so that it does satisfy the requirement or be removed. It would also mean that we could revert back to the discussion on this thread of how to really make it work. One way to make it work would be to not encrypt, but instead to actually save and validate the uuid portion of the login ticket rather than ignore it. Of course, I do realize that my analysis could end up being totally wrong, so accept my apologies in advance if that turns out to be the case :-) Thanks again, --Jon On Thu, Apr 7, 2011 at 1:03 PM, Scott Battaglia <[email protected]>wrote: > You are missing the point. Web flow parses the passed in value and looks up > the flow. The default value follows an easily guessable format allowing for > scripting login. Encrypting it with a random value makes the result > unguessable but still reversible to web flow. This means you can't script > the flow but web flow still functions correctly. Hashes won't work since we > need the value back. Uuid on its own won't work since it doesn't have the > value needed. Web flow doesn't store the uuid anywhere to my knowledge so > doing it unencrypted doesn't provide protection. > > Hopefully that is a better explanation. > > If you don't want the added protection you can disable the behavior. > On Apr 7, 2011 11:55 AM, "Jon Oler" <[email protected]> wrote: > > On Thu, Apr 7, 2011 at 12:14 PM, Scott Battaglia > > <[email protected]>wrote: > > > >> Yes the CAS protocol requirement is to be unguessable. > >> > > A random uuid is unguessable, so the concatenation of a random uuid plus > > some spring webflow details is also unguessable--before encrypting it. > > > >> Web Flow requires a guessable parsable string with particular values. > >> > > Web Flow is getting its guessable string off the end of the unguessable > > string that we're using. The whole unguessable string has to be passed > > together as a single unit to the CAS server to be of any use (is this > > correct?). In my mind, that is the key to this discussion. If there are > > any exploits available to people by knowing the SWF execution id and/or > > snapshot id in isolation (which makes them capable of doing more than > they > > could with the entire login ticket value itself), then that might be an > > issue. For example, the CAS protocol document states that users can't be > > allowed to attempt to login multiple times using the same Login Ticket. > > Just because the SWF id values can be guessed, doesn't mean that a new > > Login Ticket value can be guessed because the random uuid prefix is > > unguessable. > > > >> We solve both by attaching a random string in front of the guessable > part > >> and encrypting it. The uuid part is useless. Web Flow only cares about > the > >> second part. But if you just encrypted the existing web flow key it > would > >> always be the same value. > >> > > If the SWF execution id and/or snapshot id can be exploited in isolation > in > > ways that the Login Ticket cannot, then there may be an issue. > > Otherwise, I'm not seeing the problem. Adding a guessable value to an > > unguessable one is still unguessable. > > > > Thanks, > > > > --Jon > > > > -- > > 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
