Back after my holidays... as for the key, I'd say an optional custom web.xml context parameter is the way to go.
regards, Martin On 10/12/05, Dennis Byrne <[EMAIL PROTECTED]> wrote: > 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 > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
