Hmmm ... I was not aware of this secret gathering. I'm dennisbyrne for sf.
---- Original message ---- >Date: Wed, 12 Oct 2005 15:19:04 -0400 >From: Mike Kienenberger <[EMAIL PROTECTED]> >Subject: Re: t:saveState server/client ... or request/session >To: MyFaces Discussion <[email protected]> > >I can add you as a member of jsf-comp if you think it might be easier >to make it available there. That'd give everyone who's interested a >chance to take a look, as well as fix problems in a central area. >This is sort of a staging area for MyFaces ideas and projects, open to >anyone who'd like to be involved. Just send me your sourceforge id. > >http://sourceforge.net/projects/jsf-comp/ > >On 10/12/05, Dennis Byrne <[EMAIL PROTECTED]> wrote: >> 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 >> Dennis Byrne
