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: users@myfaces.apache.org
>
>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
