Whoops I accidentally sent a reply to you.
1 Like
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
- Server generates two things, server key and an encryption function
Server : server key and server encryption function
Exploiter: nothing
Client: nothing
- Send the encryption function towards the client, result:
Server : server key and server encryption function
Exploiter: server encryption function
Client: server encryption function
- 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
- 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
- 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
- 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
Just don’t, just check if the user has permission to do so, like an admin system.
1 Like
I can but I want players to be able to fire server when they’re not using exploits.
1 Like
That was very helpful, Thanks for sharing that knowledge.
1 Like
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
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
An exploiter can see localscripts and can easy track down the key.
1 Like
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
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
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
That’s the problem, I want to get a password for the local scripts that any client can’t read.
I made that gui so anyone can use it, But I don’t want them to do it everytime with a spam of names
That isn’t possible in a local script because it is clientside.
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.
What do you wan’t to secure? (What does the remote do)
Killing players just for an example. So I don’t want to player to access this easily
You need to make a check if the thing the player interact with ammo is, that’s how i fixed it.
1 Like
For anyone who saw this conversation, as I was asked before about it, read about time based algorithms, and finally nothing will be ever secure if the client can easily replicate the code and fire the same events, but it can stop most skids.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.