This is true, it is better than nothing. However an even better “code” is to just check if the remote is valid just like you would check if the code is valid.
Also, if you are doing codes, make sure to generate only one at the start of the game. If you generate one each time it will increase latency
Of course. In all instances, the best security is to check if the request is valid. A player can’t spend 500 cash if they only have 5. You can’t spawn the best car in the game when you don’t own it.
The point is I think the OP wants a one size fits all solution, which isn’t really secure in the first place.
@ScriptideALT
Generating a code really isn’t that intensive.
A good defense shouldn’t be dependent on whether exploiters have the ‘tools’ or knowhow on how to exploit your game. Regardless, if a client is able to fire a RemoteEvent, that would mean they know (1) the function to fire, (2) the remote event to fire and (3) the arguments used i.e. the code. This reveals that it is, in fact, truly useless.
The better defense is to sanity check all input both locally and on the server.
Let’s imagine we’ve given our user a gun, and we’ve told the local machine that it can fire n bullets per second. Locally, we would only fire the event at the defined speed. If an exploiter wished to increase that fire rate, they would need to fire the event at a higher frequency. On the server, you could track each call by every client, and if it is greater than the defined limit for the gun they are meant to be using, it can ignore the call or remove the player from the game if this occurs too often.
What?
I said it was a good defense if you don’t have the right tools. Most exploits can execute code, like firing remote events. Not all of them can get incoming and outgoing traffic. Most exploiters end up copying and pasting code, so you end up blocking a good majority of exploiters. From what I’ve seen in my games, a good deal of exploiters fail this simple trick.
Yes, the better defense is always sanity checks. However, the OP wants a solution for all remote events (which really isn’t possible, hence this conversation), which there is no real secure solution for.
Real quick… what is this security model.
Remote events exist and can be fired at will. It’s up to the developer’s server implementation to decide if that remote firing is valid. In this case it seems to be validated with a random string.
What’s been provided is a truly random generator instead of a pseudo-random generator. So either the server or client uses the function; but it can’t be both.
In the case that the client is generating the random string, it’s not secure. It’s just a random string that the server has never seen before and cannot validate.
But if the server generates the string and sends it to client for its next remoteEvent use then that’s better. Now an exploiter must intercept the random string to be able to fire any valid remote event. But then the defense stops, if the exploiter learns what to look for or if the random string isn’t immediately replaced after usage; the entire system is vulnerable.
In my opinion, its a similar reasoning that because a website only interacts over TLS connections, then its not vulnerable to cross-site request forgery or cross-site scripting attacks. The model should treat potential attackers no differently than the client. So I wouldn’t say its good practice to let the client validate itself.
But I appreciate both sides of this argument; because both are right and the exploiter is required to adjust. Just wanted to point out how the server-client model relates to this.