I think your analysis might be right. We are screwed as long as web flow requires the sequence. We may need to rewrite more of Spring Web Flow. On Apr 7, 2011 2:56 PM, "Jon Oler" <[email protected]> wrote: > 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
-- 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
