Security risk of clients having access to vector clocks
dustfinger1 at gmail.com
Fri Jan 18 12:53:03 EST 2013
Awesome, thank you so much for the help everyone!
On Fri, Jan 18, 2013 at 9:35 AM, Jon Meredith <jmeredith at basho.com> wrote:
> There is no equivalent of an SQL injection attack on the vector clock.
> If the client is able to tamper with it the only three issues I can think
> of are
> 1) deliberately corrupting it so that the put operation crashes which
> would end up with a timeout. If the application required the store and did
> not check before continuing it could be a problem.
> 2) a more sophisticated version would replace the vector clock with one
> that was considered an ancestor which would generate a sibling if allow
> mult is set yes. If you didn't resolve then you could make large objects.
> 3) similarly you could add fake entires to the clock which would make more
> work for the resolution code and slow things down until the clock was
> truncated by riak.
> If successfully decoded the information contained is a list of tuples with
> an 8 byte vnode id, and update count and a last update fine for the vnode.
> The only information leak I can see is an estimate of the number of
> On Jan 17, 2013, at 7:29 PM, Gregory Haskins <gregory.haskins at gmail.com>
> > On Jan 17, 2013, at 9:06 PM, Brian Picciano <dustfinger1 at gmail.com>
> >> 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!
> > -Greg
> > _______________________________________________
> > riak-users mailing list
> > riak-users at lists.basho.com
> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users