Re: REST etag security

On Sun, 17 Mar 2019, John P. Rouillard wrote:

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

Yes.

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

It should be autogenerated, yes.  Returning a different etag should just 
mean that edits sending the old etag fail.  Since export / import doesn't 
save session data, edits from before export / import would fail with the 
web interface anyway (cookies and CSRF tokens invalid).  So as this is 
much like session data, it probably doesn't need to be handled by export / 
import.  It *does* need to be preserved across restart of roundup-server 
or other interface (so stored either in the filesystem or in the 
database).

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

I think we should be using well-established cryptographic constructs 
rather than trying to figure out if the weaknesses of something simpler 
(such as prepending the secret to the representation) in other contexts 
are relevant here.  HMAC with SHA256 should be fine; I don't think the 
cost should be significant.

-- 
Joseph S. Myers
[email protected]