>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
