Security risk of clients having access to vector clocks
gregory.haskins at gmail.com
Thu Jan 17 21:29:22 EST 2013
On Jan 17, 2013, at 9:06 PM, Brian Picciano <dustfinger1 at gmail.com> 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.
More information about the riak-users