Check timestamps on more API calls to avoid replay attacks

[adamstallard]

As a working example, PUT and DELETE calls to /connections check the timestamp from the most recent PUT or DELETE operation and only update it if the timestamp is newer. It uses the 'removed' collection to record timestamps to DELETE /connections operations.

If we want the timestamps included in calls to
PUT /membership
DELETE /membership
POST /groups
DELETE /groups
POST /fetchUserInfo
to be useful, we need to store previous timestamps in the DB and do similar checks

Otherwise replay attacks are possible, e.g. I can repeatedly remove someone from a group if they left it at some point in the past and rejoined; I can fetchUserInfo for another user.

[abramsymons]

To make sure I have a correct understanding, you use removed collection to have access to timestamp of delete connection request. Otherwise if someone connect to another one and then delete that connection, as we don't have timestamp of delete connection request, someone can replay the first connection request.

Otherwise replay attacks are possible, e.g. I can repeatedly remove someone from a group if they left it at some point in the past and rejoined

We can simply solve this by comparing the remove request timestamp by join timestamp that is recorded in the usersInGroups. But just like in connection, more challenging scenario is when you leave a group after joining and there is no timestamp data for leaving as record is deleted. Therefor we need another collection for recording timestamps for leaving group requests.

If I understand the issue correctly, I think this issue is related to the issue #38 .
I think if we record all requests from the users with their signature in one place, we can avoid replay attacks without adding a new collection for removed records for any create/delete connection/membership/group.

[adamstallard]

To make sure I have a correct understanding, you use removed collection to have access to timestamp of delete connection request. Otherwise if someone connect to another one and then delete that connection, as we don't have timestamp of delete connection request, someone can replay the first connection request.

Exactly right

We can simply solve this by comparing the remove request timestamp by join timestamp that is recorded in the usersInGroups. But just like in connection, more challenging scenario is when you leave a group after joining and there is no timestamp data for leaving as record is deleted. Therefor we need another collection for recording timestamps for leaving group requests.

Yes.

If I understand the issue correctly, I think this issue is related to the issue #38 .
I think if we record all requests from the users with their signature in one place, we can avoid replay attacks without adding a new collection for removed records for any create/delete connection/membership/group.

I think so, too. We may even be able to deprecate the "removed" collection, or we may keep such extra collections around just to have better performance for these kind of checks.

[abramsymons]

We are checking operation hashes instead of timestamp to avoid any operation be replayed.
The hash is calculated for current operations based on operation_name + message where message includes timestamp too.