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 >
