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:
> >
>
>
