Awesome, thank you so much for the help everyone! On Fri, Jan 18, 2013 at 9:35 AM, Jon Meredith <[email protected]> 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 > updates. > > Jon > > On Jan 17, 2013, at 7:29 PM, Gregory Haskins <[email protected]> > wrote: > > > > > On Jan 17, 2013, at 9:06 PM, Brian Picciano <[email protected]> > 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! > > -Greg > > > > > > > > _______________________________________________ > > riak-users mailing list > > [email protected] > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
