This isn’t a dire thing I’m thinking about, but it’s something that popped in my head, so thought I’d ask.
If our game is sending commands as we expect (through UI, GameObject interaction, etc), then as developers, we have full control over how they’re being sent and authority is being handled. This is all good.
However, theoretically, if a cheater can send unexpected commands outside of the normal expected design, they could manipulate a server authoritative environment in unexpected ways.
I was thinking that one way to prevent particularly malicious commands made in this way is to have all commands send the client that initiated it as the first parameter, as a check to prevent unauthorized access to other clients’ server-managed resources. This is also very easy to implement.
My questions are:
Do you have any thoughts on whether commands sent in this way is even potentially a problem?
If it could be, do you have any suggested general proactive measures we can take along the way as we build the game out… or is this going to be something more like a case by case scenario, so it’s hard to give a universal answer?
Great question - yes you are right, there are always opportunities for cheating when sending data to a server, and you are also right that each vector has potentially different solutions.
You mentioned sending the client ID with the command, but if the hacker has access to other client IDs they can send command as those clients as well. The tradeoff in implementing a complex anti-cheat system is performance and potentially impacting gameplay experience.
We see even the biggest of games are constantly fighting multiplayer cheating - e.g. Riot is now requiring their kernel level anti-cheat software in order to play League in addition to Valorant. Something like that is out of the scope of coherence of course, but perhaps if you can provide some specific examples of the types of cheating you’re trying to prevent we can come up with potential ways to mitigate or at least make it non-trivial to exploit.
We’re not using that many commands, so in general, not TOO concerned. But…
One thing we have is a “Concede” command to tell the server player is giving up. Right now, that is a command we send, but I guess as I type this out, it probably makes more sense and is safer to turn that into a client-authoritative variable, so someone else can’t send a command saying you conceded when you actually didn’t… does that make sense?
I’ll have to take time to look at each on and think more about it, but I mostly just wanted to see what your guys thoughts on this is, in general. Appreciate the response
Ah, yes a very valid and common use case. Commands are the right abstraction for this so syncing a property isn’t recommended. The engine and Sdk discussed this and now have a couple of different approaches to how we can implement knowing who sent the command and preventing spoofing. So: we’re actively working on an offifcial solution to this problem - no timeline right now but it will be in a future release.
My recommendation is to forge ahead like it sounds like you are doing and this particular vector will be solved soon on our end.
Speaking of - it sounds like you have a project well in the works. Would you be interested in discussing your project at a deeper level to see how we can best support it? Feel free to email devrel@coherence.io or to DM me here if you’re interested!
