Scott and Martin, I appreciate your open and candid discussion of this topic. Thanks!
Martin has summarized my position very well. Key management in a cluster is a real pain. Unless there is truly a requirement for the symmetric encryption, then I would really like to see it removed from the CAS server implementation. Can you describe how the webflow execution id and/or snapshot id can be exploited? It seems like to be able to do anything with these values, you need to pass the entire web flow execution key (encrypted or not) in a web flow http request (so that it can be broken into its parts and used on the server)--can knowing the execution id or snapshot id individually allow for any exploits? If so, can you describe them? I'm not a spring webflow expert, but would it be possible to change the login ticket to be *only* a random uuid value (so that's all that it is exposed to the outside), associate this uuid value to a webflow execution id and snapshot id pair in the session, and then validate that the uuid is correct and use the associated execution id and snapshot id pair to reconstruct the webflow state when required? This would eliminate the need to expose webflow internals and eliminate any potential exploits based on them, if there really are any. Thanks, --Jon On Thu, Apr 7, 2011 at 10:00 AM, Scott Battaglia <[email protected]>wrote: > I'm not in front of the code but if I recall spring webflow just cares > about the parsed values. Which is why we encrypt them. I can double check > when I am at a computer. > On Apr 7, 2011 8:33 AM, "Marvin Addison" <[email protected]> wrote: > >> It's the only way to prevent exposing the execution and snapshot ids. > > > > Why are we trying to protect those again? The data they point to are > > bound to the session, so you'd have to compromise the session to > > access anything meaningful. We're protocol compliant without > > encryption as Jon noted, so I think it's important to justify the > > security requirement for encryption. > > > >> We have a constructor that takes a provided secret key rather than the > >> generated one. > > > > Providing the key is the key management headache I referred to for > > clustered deployments. > > > > M > > > > -- > > 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
