Securing a remote event by adding letters and numbers password

Help and Feedback Code Review
#1

I have been thinking of that for long time, And I have made it but the thing that I want to know if the password securing is unbreakable or can be breakable by short time.

That script gonna make sure that exploiters don’t just fire server everytime without that long letters&numbers password that I have added.
But I just want to get some feedbacks about it so I can know if it’s breakable by short time or no and improve it

Script in Serverstorage

local event = game.ReplicatedStorage:FindFirstChildOfClass("Folder"):FindFirstChildOfClass("RemoteEvent")

event.OnServerEvent:Connect(function(player,password,targetname)
	if player and password == "c794G17q9w-qOGVKcFyWG-M2ZBY2zSyz-tXo2611h4B-lRU4HMjlMR"and targetname then
		local target = workspace:FindFirstChild(tostring(targetname))
		if target then
			target:FindFirstChildOfClass("Humanoid").Health = target:FindFirstChildOfClass("Humanoid").Health - 99e99
		end
	end
end)

Local script in the gui

local password = "c794G17q9w-qOGVKcFyWG-M2ZBY2zSyz-tXo2611h4B-lRU4HMjlMR"
script.Parent.MouseButton1Click:Connect(function()
	game.ReplicatedStorage:FindFirstChildOfClass("Folder"):FindFirstChildOfClass("RemoteEvent"):FireServer(tostring(password),script.Parent.Parent.TextBox.Text)
end)

Photo of the gui if needed
image
Photo of the stuff
image

1 Like
#2

Just to know
The script is working good.
The password by python code I made.
I just want feedbacks and some talk.

#3

Exploiters can easily view the key because they can have the bytecode decompiled and read the code, they’ll figure it out.

What is the purpose of this in the callback?

If only a player would be passed as an argument, unless there’s some flaw in your implementation, it will always return true.

Preventing players from firing events
#4

It’s useless. Exploiters can easily track down the usage of your remotes and view scripts.

2 Likes
#5

Whoops I accidentally sent a reply to you.

1 Like
#6

This would not be a good way of securing a remote event, since once someone finds out about your password, everyone can fire the event, you should do something most encryption does, let me explain:

server key: used with a function to decrypt something
Encryption function: used to encrypt things one way and can’t decrypt things back

  1. Server generates two things, server key and an encryption function

Server : server key and server encryption function
Exploiter: nothing
Client: nothing

  1. Send the encryption function towards the client, result:

Server : server key and server encryption function
Exploiter: server encryption function
Client: server encryption function

  1. Client creates own key using a random function, result:

Server : server key and server encryption function
Exploiter: server encryption function
Client: server encryption function and client key

  1. Client encrypts key using server encryption function and sends it towards server, result

Server : server key and server encryption function and encrypted client key (encrypted with server encryption function)
Exploiter: server encryption function and encrypted client key (encrypted with server encryption function)
Client: server encryption function and client key

  1. Server can unencrypt client key, result

Server : server key and server encryption function and client key (unencrypted with server key)
Exploiter: server encryption function and encrypted client key (encrypted with server encryption function)
Client: server encryption function and client key

  1. Now both sides have a key they can use to send information across to each other with and the exploiter has encrypted versions of them

Now this type of encryption is bruteforceable, but extremely hard to brute force, detering exploiters from actually bothering to decrypt it anyways. I’m not a cyber security expert, I’m just explaining what I have already learnt, but if you do want to learn more about this go and search it up. Hope this helps.

Lodok3

2 Likes
#7

Just don’t, just check if the user has permission to do so, like an admin system.

1 Like
#8

I can but I want players to be able to fire server when they’re not using exploits.

1 Like
#9

That was very helpful, Thanks for sharing that knowledge.

1 Like
#10

This is still a bad idea because the client has full access to their memory and will have the key just as easily no matter how many hoops you go through.

Just don’t rely on any client authoritative design, period.

5 Likes
Help Patching An Exploit!
#11

Passwords, encryption, and other means of security implemented by game developers against players who exploit is void when they attempt to secure against the client; they do not work. The proposed solution is a nonsolution. It does not secure the remote event in the slightest.

It does not work since the password is available to the client. The client can use and manipulate all values given to it whether said data is sent by the server or hardcoded onto the client. The proposed password is exposed and, therefore, can be exploited.

This fact of game development leads to a rather simple solution—everything in the game happens in the server the game developer controls and can trust; at the same time, clients are input nodes. In other words, the client sends inputs such as key presses and commands to the server, the server runs the game, and the game gets replicated to the client. In this scenario, nothing the player does is trusted; this is called authoritative server architecture, and it is an industry-standard solution.

Take, for instance, a Chess game. There are some examples of Chess games that trust the client; this can result in exploits where the first player to go, on turn one, uses a pawn to capture the other player’s king. The capture makes no sense, but the server trusts the client, and therefore it occurs. Unlike that, in an authoritative server model, the player’s input to move their pawn gets sent to the server. The server, seeing this input does not pass its sanity checks—that the request does not make any sense, ignores the input. No changes get replicated, and it is still the first player’s turn as no valid move occurred.

Notice that the server does not directly confirm or deny the client’s inputs; it just is not processed. There is no further communication. Also, take note that the server does not take any retaliatory actions towards the client; it does not kick the player, ban them, or any other extreme action—a flaw most amateur developers make. The greatest extent a developer should do, only if they have a community-tested and polished game, is to automate a service that flags players conducting suspicious requests to investigate further; even this is considered extreme in most cases.

Narrowing the application of this model to the use case above, perhaps the server should check if the player making the request has the permission level to kill another player through this GUI?

3 Likes
#12

An exploiter can see localscripts and can easy track down the key.

1 Like
#13

Oh right sorry, I ended up explaining how to stop people trying to intercept network data, not about someone who has access to the client already

1 Like
#14

That wouldn’t work too well I’m afraid.
Exploiters can see any traffic being sent, they are also able to see what arguments is being sent, then they can just send it whenever they want and use it to their advantage.

In general, you shouldn’t focus on making ‘passwords’ and such.
Doing server-sided checks is your best friend here.

If this is for specific people in-game only, you should definitely check their player name on the server side before doing anything.
Make sure the player sending the FireServer() is allowed to use that GUI.

2 Likes
#15

As @TheEdgyDev said, just be sure to check what the client sends to the server. If a client is shooting a gun nonstop 100 times a second with a remote event, then something is wrong.

2 Likes
#16

That’s the problem, I want to get a password for the local scripts that any client can’t read.

#17

I made that gui so anyone can use it, But I don’t want them to do it everytime with a spam of names

#18

That isn’t possible in a local script because it is clientside.

#19

That’s the problem, I want it to be secure enough, But that’s for now is impossible I think. So I just need to use the classic hard style.

#20

What do you wan’t to secure? (What does the remote do)