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 <users@myfaces.apache.org> > > > >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 >
