To secure your remotes, first, create an array with around 25+ different randomized strings, second, find at least 2 encryption methods, suggestion: Base64 encoding and one other one you can probably find online or on the forums, etc. Third, when you’re firing the remote, use HttpService:JSONEncode() on your final argument only if it is a table, otherwise just fire the final encrypted string. On the server, have the decryption method for both of your encryption methods, then decrypt them the way you encrypted, so if you did something like:
local datatogiveremote = "hello";
datatogiveremote = encrypt1(datatogiveremote)
encrypteddata = encrypt2(datatogiveremote)
remote:FireServer(encrypteddata)
-- server
remote.OnServerEvent:Connect(function(plr, string)
local initialstring = decrypt2(string)
local fullydecryptedstring = decrypt1(initialstring)
end)
You need to also make sure that the string you get after fully decrypting is a valid string that you are expecting, if it isn’t, kick the player or don’t use it at all and just return.
So basically just something like that, if you’re confused about something, let me know.
I don’t see what’s wrong with it. It’s not the developers fault how insecure the scripting environment is. They should take precautions to try to keep their assets from being exploited.
All the exploiters script does is use the static key you have as the “password key” I’m guessing and then pass some type of asset Id I’m guessing to load a module.
@RiptideMorningstar
the issue looks pretty glaring
lots of your code looks to be just freely requiring whatever parameters they pass. They could pass their own module and you would in effect require their code.
You should take reasonable effort, security by obscurity is not that, this has been a thing for several decades. It would be not of the best interests to allow such a misunderstanding to continue.
It does secure the remote though? I’ve used it before and have used certain methods to keep known well experienced exploiters from using the remote unfairly.
how about we solve the actual problem which I already posted. he is not sanitizing some of the input that he is requiring; he assumes the player passes object references not numbers
they must not be experienced because all they need to do is get access to how you generate and pass keys
Which you can’t, if you obfuscate a script, the script basically becomes “empty”. Attempting to dump an obfuscated script with some type of LuaVM decompiler will just return an empty script. Attempting to constant dump an obfuscated script will also result in a similar result.
There are certain areas where security through obscurity is bad, I’ll say that at least. Keep in mind, most exploiters release their scripts which means whatever is being exploited doesn’t have some type of dynamic check of the client in your game.
This is a complete waste of development time. The exploiter has full control over one of the communicating ends of remote traffic and they can fully investigate your code to see how you are encrypting traffic. It will only serve as a temporary hurdle, once they see how you are encrypting the logic you’ll have to change it again and it will turn into a cat-and-mouse chase.
Implement server-sided checks on your remote communication to ensure the requests are valid. Security through obscurity is not real security and is a waste of time to implement, considering you can have perfect security (from developer code perspective) if you implement proper server-sided checks, probably with similar amounts of development time invested.
Please read the articles linked above if you are still confused on why security through obscurity is a bad idea. Trying to encrypt remote traffic is a noob trap.
The obscurity is not for security it’s too help keep me code from being reused by less knowledgeable programmers in their own work. My way of keeping my code to myself, and also providing an engine for people to use.
Absolutely, do your best to ensure that you have checks on the server but sometimes you cannot, like say in the sword clanning community, they used linked swords which can be resized on the client and since .Touched replicates, you can basically reach farther with the weapon than others can, you can’t check it on server, so you need to do some kind of check on the client. No one likes having to deal with client security, but saying it’s useless is an opinion honestly and that is all it is.
Of course you can check this on the server. Do distance and timing checks on the server with reasonable margins of error and you’ll catch most of the exploiters already. How do you think any triple A competitive game that attempts to fight hackers does melee/bullet hit detection? They certainly don’t rely on client-sided detection since that can be completely circumvented if the hacker is sophisticated enough.
It’s not a matter of opinion, it’s a well-grounded technical argument. Every kind of behavior can be checked against on the server in some shape or form. Any kind of check you do on the client can be circumvented.
Whilst it is true that you can always bypass client-side detection/prevention measures, it is not true that there is no place for them. It’s definitely not an industry consensus that such measures are useless because nearly every competitive multiplayer game uses them (BattlEye, VAC, Vanguard) - though it’s definitely a point of debate about how effective these systems are. You can also see similar client-side protection in quite a few popular games like Jailbreak and Phantom Forces.
I think the questions you should frame any development security decision with is:
(Most Importantly) is there any other way of detecting this behaviour except through the client?
How long does it take me to implement this?
How long would it take for a motivated attacker to bypass this?
Not all behaviours are detectable on the server - at least, not reasonably. We are constrained by limited server resources and access to internals. Some exploits would be far too expensive to detect compared to the gain you would get.
I’ll give you an example - Animation exploits. They’re annoying and leave a bad impression on your game, however they are not harmful to your gameplay. They are effectively undetectable on the server, unless you put significant amounts of work in fingerprinting animations (which is both development and computationally expensive). So, I’d argue that adding a few lines of code locally that detect non-whitelisted animation IDs is worth it. Yes - it can be bypassed, however it will eliminate most of the animation attacks from your game, and required minimal effort on your part.
Don’t get me wrong though - I don’t recommend client-side detection for anyone who is not experienced enough to already have a good grip on their client-server implementation.
