Check timestamps on more API calls to avoid replay attacks about brightid-node HOT 3 CLOSED

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.

from brightid-node.

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.

from brightid-node.

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.

from brightid-node.