Would a RemoteEvent Password catering to each player and assigned after they joined help with against ANYTHING Exploit Related?

I saw a thread on here about it, here’s my idea.

Player Joins --> Player is given a random “Password/Key” that goes into a table that witholds every single players Password/Key (Eek?)

Would it work? I’ve tried to browse through many threads to figure out what I can do to stop exploiters from finding Event Parameters, but it never seems to help any.

I’ve even immersed myself into their community, and, while i’ve gained some sense of satisfaction i’ve not gotten as far as I want to.

1 Like

You could just use a remotespy to get the key and use that to fire remotes.

1 Like

The best way would just to have sanity checks on the server and validate all parameters on the server.

Always and ALWAYS the client will find a way to retrieve that data if its on the client.

1 Like

No it would not work because the client can just look at the arguments that the remote event is being fired with. The best thing to do is to use sanity checks for example if your firing a remote event from the client to the server to buy a item then on the server check if they have enough money before giving them the item.

1 Like

Yeah, thanks for the reply, I always write any Sanity Checks I think need to be there, never trust the client and yeah. I’ll find a way though, thanks!

1 Like

Security through obscurity is never a good solution, don’t do it. Your best bet is to do server side checks for example:

Player1 shoots a gun and hits Player2 on their client, if Player1 is actually in line of sight with Player2, you damage Player2 on the server.

The client has access to pretty much anything given to them which includes variables, scripts, etc

4 Likes

Great, so just sanity checks on sanity checks.

Thanks, everyone.

I’m not sure how keys are obscure, but depending on the method keys can be really effective…
I’ve made in the past a network module that is like phantom forces but has a completely dynamic key system that changes every minute for each player uniquely.
The only times someone was actually able to bypass is when they hooked onto my getkey function since they weren’t able to figure out the math ( since I obfuscate it ) and it was easily fixed by just removing that function…
The other time was them hooking onto the stack of the obfuscator which was also fixed with some memery,
Yes yes client security isn’t always good but a key system can prove effective,
You’re also obviously expected to do server checks ( not just relying on the key system )
just wanted to share this maybe someone might find it useful lmao ( The system took 20 minutes to make btw )

3 Likes

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.

Notice:

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 still going to be able to get that key in some form, meaning an exploiter can replicate that system as well.

I and others have no clue what “fixing with memery” is, so it’s moot to mention here.

This, on the other hand, is good to add. I mean do whatever you want with your security, it’s your game, you’ll be told that STO is bad and a waste of time but the end result is your matter to deal with. At the very least, include proper security measures in your game and then you can stack any additional measures on top if you want.

2 Likes