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
