So yeah. I have been trying to make a good way to protect remote events. And recently i came up with this idea… Explaining in the pics:
I have a remote event in ReplicatedStorage
I have a script that checks everytime the event is fired inside of ServerScriptSevice
I have a module script inside ServerStorage
So the module script has different keys… Everytime you fire the event you NEED to have the right code(The code changes everytime you fire the event btw!!)
Here is the main code:
– // So is this a good way to protect remote events?
September 29, 2020, 9:34pm
This won’t really work in practice. How exactly is a client suppose to fire a event legitimately? You would need to send over a code to the client so it can actually have the correct “password” to send. And then any well versed exploiter could take that key and send it right on back and bypass your system entirely.
Another Issue I see with your implementation is that you randomize the code each time before you check. How exactly is the client suppose to know what code will be correct to send over?
You can learn more about why this is a bad idea and how it is useless here
Having a hard coded password is a bad idea - it will not work.
History has, however, proven that using a dynamic password along with some encryption or hashing algorithms can be useful in stopping the… not as capable exploiters. If you want to decrease the number of people figuring out how to exploit your game, be my guess. That won’t be able to stop all exploiters though.
TLDR; Using a password system can be effective (edit: see Phantom Forces’ old serializer), but it’s only effective in that…
Regardless of the algorithm you implement, password-based remotes are a method of security through obscurity, which isn’t real security. A dynamic algorithm that rotates the key is just that: a dynamic key. It’s still a form of STO because you’re depending on that key being valid and sending it over.
You put a blatant GetKey function in your code so that kind of retrieving would be very easy to do. You remove the function and implement another way of getting the key. The client is st…
Using a key for your remotes isn’t the greatest practice, I wouldn’t recommend doing it at all. Exploiters can find out the key and send it to the event. Instead, validate client requests on the server.
i.e. Team Changer
Player clicks GUI button to change to red team, remote event is fired with Red team. Server sees if they are in group A and Red team isn’t full, then changes team if eligible to hop over.
People say don’t trust the client because that’s one of the few strongest methods of kee…
You could use some dynamic system to make it work but why? Don’t waste your time on stuff like this just make your game with secure with server sanity checks.
Which you can learn about here
I am trying to make my game have sanity checks for see if an remote event or function is firing like extremely fast or something like that, but i cant find a way.
Or here by a nice article written by
I’ve now open sourced an implementation of one of my anticheats for use in my game Hexolus!
You can find more info and the repo links here: Hexolus' Server-sided Anticheat
This is a super long thread so read it at your own pace.
How you should secure your game
You may have seen the “never trust the client” phrase tossed around if you’ve read or created scripting support threads about remotes or game security. I’m going to explain this phrase and give some useful information ab…