Hackers can read whatever is sent through a remote event, they’ll just take the password.
If you use a password for remotes at all, which isn’t recommended, have the server change the password every 30 - 60 seconds.
4 Likes
There is no good way to protect your remotes against exploiters. The only way to make your game secure is to never trust the client, as I’m sure you’ve heard before. Never assume that any data coming from the client is correct. That being said, you should also never try to retrieve data from the client. This is bad for several reasons.
Adding a key to your remote, regardless of whether it is a static or dynamic key, is a terrible idea. If your game is vulnerable, rewrite it. You shouldn’t expect protecting your game from exploiters to be easy.
4 Likes
Actually, exploits can both read and set local variables using a reimplementation of the debug library. They can also replace the function that is returned when you index FireServer, which can be used to “log” that key.
1 Like
Just have a function that scrambles the player’s and remoteevent’s name consistently so that the server can generate it and match it. And maybe make this function automatically change every hour or something. Dont need to do more than this because if a player can access the function that generates this password, they’ll be able to fire whatever they want anyway, so it comes down to not trusting the client.
In the end, all of this is for fun(and I do pointless stuff thats similar just for fun myself), but focus on never trusting the client, thats the real task.
2 Likes
Passwords are kind of useless as the client can see it getting fired as an argument. You should instead verify the parameters on the server-side are the right type of value(I’ve had experience where exploiters would spam fire remotes with nil argument and crash the server due to the nil values causing errors). You should then do a a check on the server to verify that the client is telling the truth.
Example:
Bad idea: BuyItem:FireServer("ItemName",200) --don't trust the client to change their own money
Good idea: BuyItem:FireServer("ItemName") --have the sever check the cost of the item the client wants to buy and verify on the server that the client has enough currency for it
10 Likes
I saw a thread a few months ago, I can’t find it, and someone on there was describing what they were using for security. From what I can remember the password was “(Hower Many Times The Client Has Fired A RemoteEvents In This Server)*A Huge Number” And that would essentially make pretty good security as the exploiter will never know how many times the client has fired remote events. I would still use good security and checks on my remote events, this is just another wall of defence I wanted to have.
2 Likes
This stops people using remote event trackers, NOT people reading your code.
I suppose in this case you have to trust the client. Just ensure the player can’t get more XP than possible, so exploiters, could only get the maximum XP, no better.
1 Like
I actually did this in one of my older games before I found out better options you can always hide a password if you need to access it client side then I advise hiding it deep inside of players folder somewhere and name it value create it as a number value then use math.random(100000000,999999999) when the server loads up and anytime that the value has been seen by a player. Exploiters will only see the random number and will not have a path to that value they won’t know what it is
Other then this I advise you to put all your shop items inside of replicatedStorage as long as you have an FE game and to add values of the shop items inside of each item with the price of the item. You can resend the shop weapon price to the server if you wanna catch exploiters and kick them for attempting if you want by checking if the price was increased or decreased from the real value from the price you set into the item. Alternatively instead of simply kicking the player you can set a value that goes through datastore one the attempts that the player has exploited and if the number goes above 3 then use plr:Kick(“The system has detected that you were exploiting and you have been perm banned”).
Note that people can’t force others to exploit they can only exploit themself as long as your game is FE.
2 Likes
“Three strikes and you’re out” is how most Roblox games do it. I set it to overdrive. Mess up once, you’re perma banned, and you don’t even get a good message saying what you did wrong. I run extensive unit testing on my remote events to make sure an innocent client can never be caught.
3 Likes
A fun thing to do is to create a remote called EnableGodMode or something and then just kick anyone that calls it. It’d be really fun to track it and see how many players fall for it.
12 Likes
Shhh…don’t give away my secrets 
(I have a lot of honeypot things like that, my game’s not out yet to have any data on them, but I’ll make sure to release them in a long blog post! Shhh)
3 Likes
Found a model that may interest you, maybe you could see how it works and then generate your own strings/passwords.
If you want a random key, just use HttpService:GenerateGUID()
4 Likes
I know how to generate a key, I just needed to know how to make it more secure.
My question would be, how would you get the information to the client and server about what the password is without the client seeing it themselves? It’s practically impossible. You should focus more on making the invocations for the remotes more secure themselves and validating the input based on server-controlled conditions in my opinion.
In your example of placing / destroying items, you can keep track of these things on the server and validate whether the action they’re trying to do is valid. For example, you could introduce a distance limit for how far they can place / destroy them from. As well as validating the thing they’re trying to destroy is owned by their client.
If it’s a situation where they’re able to destroy other people’s property, then introduce a cool-down delay that’s not too annoying and is realistic to what you’d expect. Just try and look at each one of your issues through a different perspective and try and come up with a clever way to protect your game against people trying to exploit those vulnerabilities.
9 Likes