Welcome back. That's what I ended up doing. That blew up the containerless unit test though so it also looks for system property .
---- Original message ---- >Date: Sun, 16 Oct 2005 19:58:19 +0200 >From: Martin Marinschek <[EMAIL PROTECTED]> >Subject: Re: t:saveState server/client ... or request/session >To: MyFaces Discussion <[email protected]> > >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 Dennis Byrne
