One thing I expect to add in 4.1 is an optional service that can be
used by DataSqueezer, and others, to encrypt/decrypt a stream that
will ultimately be exposed to the client.  The default implementation
will do nothing, a provided implementation can do whatever is
necessary.  I'll have to think of a reasonable way to "salt" the
encryption, such that repeat attacks won't work.  The advantage is
that there's never any reason to expose the decryption key on the
client side; we can use simple (not public) encryption on the server
side ... just treating the client as a "dumb byte holder".  Security
and encryption get much more complicated when the we want to encrypt
in one place (the server) and decrypt elsewhere (the client).

I suspect that an extreme solution might not store the encrypted data
on the client at all, but would store the unencrypted bytestream on
the server (in a database or flat file) and send back to the client a
token used to access that bytestream. That introduces new
complications ... where is the data stored and for how long, but would
be much more secure. Still, the token would need something to prevent
repeat attacks ... but it could still be pretty small.

On 11/30/05, Kent Tong <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Please check out the advice by a security expert on how to secure
> the VIEWSTATE in .NET:
> http://www.securityfocus.com/archive/1/397375/2005-04-30/2005-05-06/2
>
> --
> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to