Oh, and here's another one ;-) SSL encrypts everything. This is often a problem for high volume systems where there is only a small chunk of data needing to be hidden.
---- Original message ---- >Date: Wed, 12 Oct 2005 22:02:39 +0200 >From: Werner Punz <[EMAIL PROTECTED]> >Subject: Re: t:saveState server/client ... or request/session >To: [email protected] > >Ok sorry did not think of that anymore, understandable after >13 hours of coding ;-) > >Werner > > >Mike Kienenberger wrote: >> Werner, >> >> We're talking about encryption of the client state data at the client, >> not of the data channel between the client and the server. Right now, >> an end-user can do a view-source, then Base64 decode the state tree >> field to see all stored data. Depending on what the application is >> doing, this could contain sensitive information. It's a >> recommendation of the JSF 1.2 spec to encrypt this data. >> >> On 10/12/05, Werner Punz <[EMAIL PROTECTED]> wrote: >> >>>I do not think encryption is that important, signing probably yes, >>>but if you want encryption you always can switch to a ssl layer which >>>is easier to handle. >>> >>> >>> >>> >>>Mike Kienenberger wrote: >>> >>>>I did a search on the JSF 1.2 spec, and the four references to >>>>encrypting are all vague and general ("It is advisable that this >>>>[client saved state] information be encrypted and tamper evident, >>>>since it is being sent down to the client, where it may persist for >>>>some time."), so we're on our own here. >>>> >>>>There's a few different approaches. The first is to simply generate >>>>a new key on startup and effectively expire all sessions when the >>>>server is restarted. It's not a bad "first draft" implementation. >>>>However, it won't work in clustered environments nor across restarts. >>>> >>>>Saving the key in each session might work. The environment may >>>>preserve server-side sessions across restarts, depending on the >>>>configuration. >>>> >>>>Another approach is to find some centralized location to store the >>>>encryption key. I'm not really sure what's available. Maybe a file >>>>in "temp", and that has its own security concerns, but those are >>>>probably subordinate to client-side state saving concerns. >>>> >>>>As you stated, you could also store the key in the application as an >>>>unchangable attribute. Maybe that's not a bad way to go either, but >>>>if that were the case, I'd like to be able to store it as a JNDI >>>>property. I'd be a bit concerned about keeping the same key forever. >>>> I think some "random" data would need to be padded into the state >>>>values, especially for shorter state values, in order to keep the >>>>encryption secure. >>>> >>>>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. >>>> >>>>On 10/11/05, Dennis Byrne <[EMAIL PROTECTED]> wrote: >>>> >>> >>> >> > Dennis Byrne
