Security risk of clients having access to vector clocks

Brian Picciano mediocregopher at
Thu Jan 17 21:16:40 EST 2013

If the only thing the client could potentially mess up is the specific key
that vector clock is for then that's fine, I just wanted to check that
there wasn't some equivalent of a sql injection which could be done to
manipulate/delete other keys.

On Thu, Jan 17, 2013 at 9:12 PM, Michael Clemmons
<glassresistor at>wrote:

> Manipulating the vclock client side in theory could be used to affect what
> data is stored.  I wouldnt say this is a large problem but I would think
> about whats being stored and if being able to say force a revert is
> profitable.
> On Jan 17, 2013 6:07 PM, "Brian Picciano" <dustfinger1 at> wrote:
>> A web app that we're building is designed in such a way that the vector
>> clocks returned from a bucket with use_multi:true will be sent to the
>> client, and the client will then return that vector clock in subsequent
>> requests so that we can keep track of state conflicts in riak.
>> My question is: are there any security risks in doing this? We've
>> obfuscated the vector clock (and never call it the vector clock on the
>> client side), but that's just security through obscurity, and probably
>> wouldn't hold up very long. Would a client be able to get any meaninful
>> information out of a vector clock, or manipulate it in such a way that when
>> they return it it could harm the database? Are there any ways we could
>> combat this?
>> _______________________________________________
>> riak-users mailing list
>> riak-users at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the riak-users mailing list