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: > Yeah. Martin said the same thing off the list. I bought a > book on cryptography yesterday and I'll be putting a patch in > the JIRA in a few weeks. > > By the way, the encrypted data must be decrypted w/ the same > key. Normally this is no problem, but my app blows up when I > restart it and hit F5. In order to prevent the key from > being regenerated for each application start up (and to make > the solution work in clustered envs), the app developer needs > to supply a secret from which the key is generated. Does > anyone have a prefference for where this secret should > be? .properties, DD, faces-config ? I really don't care ;) > > ---- Original message ---- > >Date: Tue, 11 Oct 2005 16:29:21 -0400 > >From: Mike Kienenberger <[EMAIL PROTECTED]> > >Subject: Re: t:saveState server/client ... or > request/session > >To: MyFaces Discussion <[email protected]> > > > >Hey Dennis, > > > >Rather than try to implement this per component (like with > >saveState/safeState), why not just implement it once in the > >stateManager? saveState and every other component all go > through > >this anyway. > > > >It's probably just a matter of checking the JSF 1.2 spec and > insuring > >that what you're doing meets what's there (although, to be > honest, > >since MyFaces is only 1.1 compliant, it doesn't have to meet > the JSF > >1.2 spec -- someone else can deal with that. Dealing with > it now > >would just make the upgrade path easier in the future.) > > > >-Mike > > > > > >On 10/6/05, Dennis Byrne <[EMAIL PROTECTED]> wrote: > >> I can't commit myself to this for every component in the > >> project Martin. I have however created a sibling of > >> saveState called safeState . It acts just as saveState > >> except it makes use of an EncryptionUtil . > >> > >> EncryptionUtil uses several classes under javax.crypto, so > >> there are no third party deps. Unfortunately the static > key > >> generator presents a challenge in a cluster. I haven't had > >> problems after a search and replace on all t:saveState tags > >> for my project. Can't say how it would perform in a high > >> volume environment. I also have unit tests. If this ends > up > >> behaving itself in my project over a week or two, are you > >> interested? > >> > >> > >> ---- Original message ---- > >> >Date: Wed, 5 Oct 2005 09:30:21 +0200 > >> >From: Martin Marinschek <[EMAIL PROTECTED]> > >> >Subject: Re: t:saveState server/client ... or > >> request/session > >> >To: MyFaces Discussion <[email protected]> > >> > > >> >Ok, > >> > > >> >to shed some light on this: > >> > > >> >- in the JSF RI, there is encryption on the client side - > we > >> have not > >> >implemented it so far, (this was after 1.1) cause we have > no > >> one here > >> >with too much time and experience in this. It should be > not > >> too hard > >> >though with the RI as an example and the java security > >> classes! Anyone > >> >fancy working on this? > >> > > >> >- on the server end of things, the RI saves the state of > the > >> last 15 > >> >requests or so - this has been after 1.1. as well, and > >> nobody had the > >> >time to do so on our side either... any contributions here > >> are very > >> >welcome! > >> > > >> >- MyFaces is serializing whatever the state saving > settings > >> are. So > >> >with MyFaces, you get a smaller memory footprint on the > >> server when > >> >the session is serialized, but the implementation does the > >> additional > >> >work of serialization/deserialization. I really think we > >> should have > >> >this as an option, any contribution is very welcome here > as > >> well! > >> > > >> >regards, > >> > > >> >Martin > >> > > >> >On 10/5/05, Dennis Byrne <[EMAIL PROTECTED]> wrote: > >> >> >I guess it would be possible to implement a custom > >> >> >state-saving/state-restoring mechanism that encrypts > the > >> >> data using a > >> >> >key stored in the user session. > >> >> > >> >> ... or use a converter that did the > encryption/decryption ? > >> >> > >> >> >Why would the objects stored in the user session on the > >> >> server be > >> >> >serialized at all, unless webserver clustering is > enabled? > >> >> > >> >> This is a good point and it probably explains the > question > >> I > >> >> asked in a post that hit the list about 15 minutes > ago. I > >> >> was under the impression the value was serialized in > both > >> >> scenarios from past discussions I have had on the list. > >> >> > >> >> http://www.mail- > >> >> archive.com/[email protected]/msg08176.html > >> >> > >> >> >That does lead to some pretty heavy memory management > at > >> the > >> >> server end. > >> >> > >> >> What if it was serialized to disk Simon ;-) > >> >> Dennis Byrne > >> >> > >> > > >> > > >> >-- > >> > > >> >http://www.irian.at > >> >Your JSF powerhouse - > >> >JSF Trainings in English and German > >> Dennis Byrne > >> > Dennis Byrne >
