Security risk of clients having access to vector clocks

Gregory Haskins gregory.haskins at
Thu Jan 17 21:29:22 EST 2013

On Jan 17, 2013, at 9:06 PM, Brian Picciano <dustfinger1 at> wrote:

> Are there any ways we could combat this?

I can't comment on what might be at risk from a Riak perspective, but as a general comment you could combat client-side tampering using crypto (perhaps you have already considered this option, I am not sure). 

For instance, you could attach an HMAC to the vector clock before returning it client side as a token, and then validate the HMAC when the token is passed back to you in the future.  This will add overhead for both generating and validating the token, but it could alleviate exposure against db tampering.  (Note that an HMAC alone will not protect you from replay of a previously issued vclock+HMAC, however.  For that you will need to be more clever).  Generally, I prefer to handle this stuff server side attached to the session, which I know isn't "RESTful", but it is easier to solve the security problems this way.

Good luck!


More information about the riak-users mailing list