Remote event passwords?

Help and Feedback Scripting Support
#1

I’m almost done with my game and I want to make sure it is secure from exploiters. I thought of a good idea would be to send a “password” as a parameter through the remote event. So it would look something like this:

Client

Game.ReplicatedStorage.GiveCoins:FireServer(482947)

Server

Game.ReplicatedStorage.GiveCoins.OnServerEvent:Connect(function(password)
     If password == 482947 then
          coins = coins + 100
     end
end)

Would doing this work? Why don’t I see other people doing this?

5 Likes
#2

This wouldn’t be secure in the slightest.

Exploiters can unfortunately see all of the variables in your game, and what’s passed through RemoteEvents.

I also strongly advise you to not fire events such as giving coins to a player on the client - I recommend you do all of that on the server - without events.

14 Likes
#3

Because exploiters can see everything in local scripts, and so they’d be able to see the “password” regardless. Thus it’d be useless.

6 Likes
#4

Security through obscurity isn’t really secure. It just takes one exploiter to use RemoteSpy—they don’t even have to decompile your LocalScripts—and that method won’t be effective at all anymore. Also, that specific code will never work, since password will always be the player who fired the event.

9 Likes
#9

I’d like to add onto this a little bit, to emphasise good points that have already been made by @TheRings0fSaturn and @rogchamp

It also makes no difference if you’re using a static password or a dynamic password (such as a key that changes via a pseudo-random key). In order to generate a pseudo-random key, you need to store the state of that which can be called as the regular client and it will be generated for the exploiter.

You’re best doing what has already been suggested, making sure to never trust the client as much as feasibly possible. You can obscure your RemoteEvents by sending your information in a custom binary format, but this is only an additional layer of obscurity and it isn’t guaranteed to be 100% secure, as nothing is.

6 Likes
Help Patching An Exploit!
#10

These are called Remote Keys and aren’t very secure, as the client has to calculate/get it somehow.

1 Like
#12

This wouldn’t work although you can catch exploiters by adding “Fake Remote Events”, so you create a RemoteEvent called “GetAdmin” or anything thats interesting, everytime its fired you can Ban the player.

3 Likes
#13

Unfortunately,

This might not work.

1 Like
#14

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 it stops beginner/intermediate level exploiters. As you have most likely seen a number of times, never trust the client. Place all critical infrastructure on the server. That is how you prevent exploiters almost entirely.

3 Likes
Is this a good way to protect remote events?
#15

Let’s use the SynapseX Remote Spy as an example. It prints the Remote and Args so it would be extremely insecure to have a static password.

Picture of what it looks like (Not mine): image

2 Likes
#17

you can patch remote spy with this method How do you detect dark dex? - #488 by tr1stt4n

1 Like
#18

No. This is not secure in the slightest. A remote password is totally useless.

You should instead design your game in a way (security by design) that no matter how they send remotes it doesnt affect your game negatively.

1 Like
#20
1 Like
#21

Might be the reason you have a dynamic * password * or as i like to call it * key *

1 Like