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