Good, I'll just email it to your gmail account before I even open the issue.
---- Original message ---- >Date: Wed, 12 Oct 2005 14:51:38 -0400 >From: Mike Kienenberger <[EMAIL PROTECTED]> >Subject: Re: t:saveState server/client ... or request/session >To: MyFaces Discussion <[email protected]> > >Yeah, that's a good point. I'm going to enhance whatever you come up >with to add the ip address into the state and validation. Maybe you >can leave in a hook for "adding" other authentication info into the >mix. Or I suppose I can create my own delegating StateManager to do >it. Might be better that way. > >On 10/12/05, Dennis Byrne <[EMAIL PROTECTED]> wrote: >> >Saving the key in each session might work. The environment >> may >> >preserve server-side sessions across restarts, depending on >> the >> >configuration. >> >> Yes, and javax.crypto.spec.SecretKeySpec implements >> Serializable. There are of course risks w/ a key being >> stored in serialized sessions. >> >> >I'd also like to recommend that the data is signed rather >> than just >> >encrypted. For me, having a cryptologically-signed state >> is more >> >important than encrypting the state. I'm not concerned >> that the >> >end-user can read the state (after all, most of the state is >> visible >> >in another form already). I just don't want the end-user >> to be able >> >to modify it. >> >> For the short term , I'll just focus on encryption. The >> immediate problem I have is that I am using saveState for >> conversations. This lets an attacker post their own model. >> It also lets people see the values of properties that I do >> not intentionally render. Encryption of course guarantees >> confidentiality (but in this case, only between the server >> and itself) while a signature guarantees integrity. >> >> You are right however that encryption is not enough. >> Consider the following paranoid example. Mike K. is an admin >> and Sean S. is not. Sean however is on the same network >> segment as Mike which means he can listen for Mike's state. >> Sean can then post Mike's state, and because the key is >> global, the app will gladly decode, decrypt and restore >> Mike's priveledged view. He can totally by-pass any security >> at the database and application levels. Damn that Sean ;) >> >> Dennis Byrne >> Dennis Byrne
