You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2012/10/04 21:04:22 UTC
HMAC signatures
Just checked in the code for HMAC signatures on form data (or any
other serialized object data on the client, such as the "client"
persistent field strategy).
Basically, form t:formdata fields are now prefixed with the HMAC code;
on submission, Tapestry can verify that the HMAC code matches the
binary stream encoded as Base64 to ensure that the data has not been
tampered with.
Users will want to configure their private pass phrase using a newly
defined symbol. If left unconfigured, there will be a runtime error
logged (not an exception, just an error to encourage users to select a
private pass phrase).
Very pleased with the result, though I don't know if it will affect
performance in any great way. Fortunately, it is based on symmetric
(private) keys, which are relatively cheap (public key encryption is
very expensive, such that in normal usage, the public key is used to
encode a randomly chosen symmetric key, and the message payload is
encrypted with the symmetric key; encoding an entire message with the
public key would be prohibitively expensive).
Currently, it is hard coded to use HmacSHA1 as the signing algorithm;
I flirted with making this configurable as well, but decided to wait
and see if that is necessary.
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by Nelson Rodrigues <ne...@nelsonjrodrigues.com>.
You could replace "DEFAULT" with something that's unique for any
application, for example the checksum of AppModule class file.
This should be fairly secret, and stable across clusters.
Nelson.
On 05/10/2012, at 13:34, Massimo Lusetti <ml...@gmail.com> wrote:
> On Fri, Oct 5, 2012 at 12:35 PM, Dmitry Gusev <dm...@gmail.com> wrote:
>
>> I know, but isn't other default (non-random) value would be a priori known?
>>
>> Random value isn't good for cluster deployments, as was already mentioned
>> before.
>>
>> So by default the HMAC signature wouldn't be much secure (if key equals to
>> default), but at least it will work in cluster the same way as assets do
>> (using application version).
>>
>> If you want more secure signatures you may specify passphrase explicitly
>> also.
>
> My point is I don't see any difference between the "DEFAULT" default
> value and the application version.
>
> Cheers
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Oct 5, 2012 at 12:35 PM, Dmitry Gusev <dm...@gmail.com> wrote:
> I know, but isn't other default (non-random) value would be a priori known?
>
> Random value isn't good for cluster deployments, as was already mentioned
> before.
>
> So by default the HMAC signature wouldn't be much secure (if key equals to
> default), but at least it will work in cluster the same way as assets do
> (using application version).
>
> If you want more secure signatures you may specify passphrase explicitly
> also.
My point is I don't see any difference between the "DEFAULT" default
value and the application version.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by Dmitry Gusev <dm...@gmail.com>.
I know, but isn't other default (non-random) value would be a priori known?
Random value isn't good for cluster deployments, as was already mentioned
before.
So by default the HMAC signature wouldn't be much secure (if key equals to
default), but at least it will work in cluster the same way as assets do
(using application version).
If you want more secure signatures you may specify passphrase explicitly
also.
On Fri, Oct 5, 2012 at 1:57 PM, Massimo Lusetti <ml...@gmail.com> wrote:
> On Fri, Oct 5, 2012 at 9:35 AM, Dmitry Gusev <dm...@gmail.com>
> wrote:
>
> > Can't we just use application version by default?
>
> The whole point here is to protect against tampered data, so a known
> value is useless.
>
> Cheers
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: HMAC signatures
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Oct 5, 2012 at 9:35 AM, Dmitry Gusev <dm...@gmail.com> wrote:
> Can't we just use application version by default?
The whole point here is to protect against tampered data, so a known
value is useless.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by Dmitry Gusev <dm...@gmail.com>.
Can't we just use application version by default?
On Fri, Oct 5, 2012 at 11:22 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
> On 05.10.2012 00:22, Howard Lewis Ship wrote:
> > On Thu, Oct 4, 2012 at 3:18 PM, Massimo Lusetti <ml...@gmail.com>
> wrote:
> >> On Thu, Oct 4, 2012 at 9:04 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
> >>
> >>> Users will want to configure their private pass phrase using a newly
> >>> defined symbol. If left unconfigured, there will be a runtime error
> >>> logged (not an exception, just an error to encourage users to select a
> >>> private pass phrase).
> >>
> >> Why not generate a random string if not supplied.
> >> Doesn't it work better then the "DEFAULT" string?
> >
> > That would not work in a cluster; different servers in the cluster
> > would not be able to read each other's streams. Yes, usually, its
> > based on sticky sessions, but even then, there's fail-over to
> > consider. Also, a server restart would not only lose client sessions,
> > but would generate a new random key, so any forms would become
> > unsubmittable even if they did not depend on server-side session
> > state.
>
> We could store a randomly generated key in the session for those requests
> where a session exists. If
> none exists use the default. I know, we are trying to store as little as
> possible inside the
> session, but the few bytes of the key shouldn't be a problem.
>
> Uli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: HMAC signatures
Posted by Ulrich Stärk <ul...@spielviel.de>.
On 05.10.2012 00:22, Howard Lewis Ship wrote:
> On Thu, Oct 4, 2012 at 3:18 PM, Massimo Lusetti <ml...@gmail.com> wrote:
>> On Thu, Oct 4, 2012 at 9:04 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>>
>>> Users will want to configure their private pass phrase using a newly
>>> defined symbol. If left unconfigured, there will be a runtime error
>>> logged (not an exception, just an error to encourage users to select a
>>> private pass phrase).
>>
>> Why not generate a random string if not supplied.
>> Doesn't it work better then the "DEFAULT" string?
>
> That would not work in a cluster; different servers in the cluster
> would not be able to read each other's streams. Yes, usually, its
> based on sticky sessions, but even then, there's fail-over to
> consider. Also, a server restart would not only lose client sessions,
> but would generate a new random key, so any forms would become
> unsubmittable even if they did not depend on server-side session
> state.
We could store a randomly generated key in the session for those requests where a session exists. If
none exists use the default. I know, we are trying to store as little as possible inside the
session, but the few bytes of the key shouldn't be a problem.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think a random passphrase, rather than a default one, will cause
more confusion among those who don't see that it needs configuring
(and don't read their console errors!). I don't want a flood of
"Tapestry is broken! What is HMAC?" messages on the user mailing list.
On Thu, Oct 4, 2012 at 4:44 PM, David Rees <dr...@gmail.com> wrote:
> On Thu, Oct 4, 2012 at 3:49 PM, Lenny Primak <lp...@hope.nyc.ny.us> wrote:
>> I don't think that for lazy developers it needs to be secure at all :)
>
> Yep. If not configured, issue a big warning, but continue running.
> Then they would be no worse off than they are now.
>
> -Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by David Rees <dr...@gmail.com>.
On Thu, Oct 4, 2012 at 3:49 PM, Lenny Primak <lp...@hope.nyc.ny.us> wrote:
> I don't think that for lazy developers it needs to be secure at all :)
Yep. If not configured, issue a big warning, but continue running.
Then they would be no worse off than they are now.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
I don't think that for lazy developers it needs to be secure at all :)
On Oct 4, 2012, at 6:48 PM, Massimo Lusetti wrote:
> I feel I was not clear enough.
>
> To protect the lazy developers, the newcomers or simply the unwary
> user I would make the default value a random generated string with a
> big warning in the log and a big "pay attention" in the docs and
> release notes.
>
> This goes with the feeling that an expert developer which has to face
> a deploy to a cluster is more heedful and would set the value to a
> known and beefy one.
>
> The current implementation feels like a false sense of security for
> the first type of developer even more by the fact that this has been
> added lately to the plate (it could slip through to the newcomers) so
> if a random generated string is not accepted I would make it required,
> with a nice RuntimeException, if not set.
>
> Cheers
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by Massimo Lusetti <ml...@gmail.com>.
I feel I was not clear enough.
To protect the lazy developers, the newcomers or simply the unwary
user I would make the default value a random generated string with a
big warning in the log and a big "pay attention" in the docs and
release notes.
This goes with the feeling that an expert developer which has to face
a deploy to a cluster is more heedful and would set the value to a
known and beefy one.
The current implementation feels like a false sense of security for
the first type of developer even more by the fact that this has been
added lately to the plate (it could slip through to the newcomers) so
if a random generated string is not accepted I would make it required,
with a nice RuntimeException, if not set.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Oct 5, 2012 at 12:22 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> That would not work in a cluster; different servers in the cluster
Yes I know but anyone who deploy to a cluster would be loudly advised
to set the directive to a known value, but for all the other
deployments there would be no reason to worry about.
> would not be able to read each other's streams. Yes, usually, its
> based on sticky sessions, but even then, there's fail-over to
> consider. Also, a server restart would not only lose client sessions,
> but would generate a new random key, so any forms would become
> unsubmittable even if they did not depend on server-side session
> state.
This is case is valid only for case where a user GET a form then
populate it while a new deploy is running and submit it after the
deploy is finished.
>> It could lowered the error to a warning too.
>
> To be honest, in a perfect world, it would blow up with an exception
> ... but that's too draconian, especially for something added this late
> in the game. Warnings are completely ignored.
Remember we are in the case of a lazy developer who has not set the
value or even has not read the release notes nor the doc so.
I want to protect the lazy developer in the typical "one server with
all in" situation.
I've talked about lowering the error to warning in case of a
completely random generated value not for the current hardcoded on
which I agree that a RuntimeException would be more wise.
> I'm even tempted to add a message to the AlertManager service, to
> really get it in front of the developer's eyes, pronto.
If the current implementation is choosen I would prefer a
RuntimeException in any case.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Thu, Oct 4, 2012 at 3:18 PM, Massimo Lusetti <ml...@gmail.com> wrote:
> On Thu, Oct 4, 2012 at 9:04 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>> Users will want to configure their private pass phrase using a newly
>> defined symbol. If left unconfigured, there will be a runtime error
>> logged (not an exception, just an error to encourage users to select a
>> private pass phrase).
>
> Why not generate a random string if not supplied.
> Doesn't it work better then the "DEFAULT" string?
That would not work in a cluster; different servers in the cluster
would not be able to read each other's streams. Yes, usually, its
based on sticky sessions, but even then, there's fail-over to
consider. Also, a server restart would not only lose client sessions,
but would generate a new random key, so any forms would become
unsubmittable even if they did not depend on server-side session
state.
>
> It could lowered the error to a warning too.
To be honest, in a perfect world, it would blow up with an exception
... but that's too draconian, especially for something added this late
in the game. Warnings are completely ignored.
I'm even tempted to add a message to the AlertManager service, to
really get it in front of the developer's eyes, pronto.
>
> --
> Massimo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HMAC signatures
Posted by Massimo Lusetti <ml...@gmail.com>.
On Thu, Oct 4, 2012 at 9:04 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Users will want to configure their private pass phrase using a newly
> defined symbol. If left unconfigured, there will be a runtime error
> logged (not an exception, just an error to encourage users to select a
> private pass phrase).
Why not generate a random string if not supplied.
Doesn't it work better then the "DEFAULT" string?
It could lowered the error to a warning too.
--
Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org