Re: REST etag security

Hi Joseph:

In message <[email protected]>,
Joseph Myers writes:
>The REST code generates an etag as an md5 hash of a representation of
>item properties.
>
>That includes properties to which the user does not have access.
>Depending on the schema, that means it could be used as an oracle to
>test guesses for values of such properties by generating hashes with
>guessed values for those properties inserted and seeing if those
>match the provided etag.

Nice catch.

>This could be addressed by using HMAC with a per-instance random
>secret key, instead of a simple hash function,

This I think this is the easier to implement alternative. It doesn't
require schema changes.  Is "per-instance" the same as per-tracker?
Am I correct that the secret could be an autogenerated random number
or string that is stored when the tracker is initialized and preserved
across restart, dump/restore etc.

What is the impact of changing/losing that random secret? Are there
any issues with returning a different etag if the representation
hasn't changed? I assume not but....

I chose md5 because I am concerned about the expense of calculating
the etag. Do we need to use an HMAC? Would prepending the secret to
the representation then performing the md5 be as good as an HMAC?

If we prepend the secret then calculate the checksum, is it possible
to reverse engineer the secret by getting the etags for a bunch of
issues, msgs etc. assuming they all use the same secret? Would
replacing md5 with sha1 or sha256 be better than using it with md5?

I think an etag should be provided with all web access mechanisms:
xml-rpc, web interface, rest .... This would help with detecting
collisions in an edit session. IIRC the last activity date is used as
a validator, but that is a weak validation. Replacing it with an etag
would be good.

Ideally we should be calculating it at the database level, but that
is more than I can do right now.

>or by storing a random etag in the database for each item (generated
>automatically like the 'activity' property) so it's not related to
>item properties at all, just changes to a new random value whenever
>any other change is made.

A per object secret solves the issue of calculating the secret by
collecting a bunch of etags. But it requires schema changes and code
in the database layer for all supported backends.

Is the cost of calculating an HMAC with a single security token low
enough that we don't care? I would like to not prevent roundup from
running on a low powered appliance (e.g. roundup as a GTD (getting
things done) tool.

Thoughts?

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.