How could I go about making a random "password" for remote events for security against exploiters?

What I mean by this is a system where a random “password” of sorts is generated whenever a player joins the game. This “password” would be used whenever the client fires a remote event to the server, and if the password is wrong, or not there at all, the player is kicked/banned.

But how would I go about doing this, and how could I go about making sure the exploiter can’t find it out? or is there a better method of security that I can use?

EDIT: And please don’t just say “Just don’t trust anything n the client” or whatever. Sometimes you simply have to use remove events for important things like, in my case, destroying and placing items.

4 Likes

They can ALWAYS find it out,
But if you really want to spend time on it, take a look at this.
Secure the events server side, check them.
https://devforum.roblox.com/t/securing-remoteevents-with-pseudorandom-numbers-en-de-cy-ro/112628

3 Likes

That thread was deleted because of hate or whatever.

2 Likes

I just tried the link and you’re right :stuck_out_tongue: usefull

Sometimes you simply have to use remove events for important things like, in my case, destroying and placing items.

No, you don’t, at least you don’t ever need those without having security. Stop this security through obscurity nonsense. If your game gets an inkling of popularity, the highly skilled cheaters will write custom cheats for your game and release those. Stop. I’ll give you the phrase you hate because it’s the phrase you should LIVE by, don’t trust the client.

Secure your remote events with THAT, not stupid passwords or pseudo random number generators or whatever else you can think of to avoid the actual problem. In your case, do something like checking if the player has the item, if they’re in placing distance, etc.

14 Likes

Just don’t trust the client, in your example “destroying and placing items.” you could easily do checks on the server for that as long as you create the system where it isn’t fully local.

I agree though that sometimes you can’t do checks on the server, but that is very rare, I have many features in my games and only one of them is so local that I can’t do proper checks on the server. I’m currently working on figuring out how I could secure it, maybe transfer half of it to the server or something like that, not sure yet.

2 Likes

Yes, but even if they have the item the player could make an auto destroy bot or a bot that builds a huge base.

Make it so they can only destroy or build X number of things every Y seconds, Y being, like, 1/20.

But even they could just make a slower bot. Look at the booga booga cheats. That’s what I mean. Cheats that destroy everything that’s breakable on the server/.

I have a minigame where random circles roll down the screen and you have to press buttons at the right time, if you get it correctly the client fires a remote event and the server rewards them exp, I can’t secure this on the server because the server cannot tell if the player is playing the minimage or see what they are doing at all, therefore I either have to transfer the minigame and make some parts of it server-sided or find another way.

2 Likes

My mistake, I was completely wrong on the statement that you can ALWAYS secure. It’s a bit early in the morning :yum:

1 Like

I don’t know anything about Booga Booga cheats because I don’t play Booga Booga.

Think of it this way, if the player has the power to make “auto destroy bots”, that’s a problem with your game’s design (not programming, game design). Figure out a game design solution that keeps players happy and cheaters angry. For a personal example, aimbots plague shooting games, even on Roblox. I didn’t want to go through the hassle of making protection against that and keep it constantly updated because in the end, you can’t prevent it. So what did I do? I just made every weapon in my game projectile based, and none of the projectiles are absurdly fast. Now aimbots are going to have to do a lot more math to write an aimbot, that I don’t expect people to write.

2 Likes

Fair enough, but if your game comes popular, people will write code for it.

Sure, people have written projectile aimbots in the past, but because of the way my game is designed it’s not an issue, aimbots can be played around because all the weapons are projectiles. Aimbots are no longer an issue in my game, even if everyone has one.

Fair enough. Anyways, imma go. Cya!

1 Like

I have a copy of the tutorial you stated however it’s A) translated into Welsh B) I’ve been asked not to share it.

The usage of passwords to secure remove events is not advised based on how easily it can be cracked. You may do so but be aware that it may not be secure.

1 Like

To clarify, not MAY not be secure, it isn’t.

Create a remote event the tells the server whether the clients in the minigame. When the client is in the minigame, restrict them from doing anything else on the server to avoid them putting it permanently into minigame mode then playing the game as normal. Throttle the rate at which the exp event can be triggered.

Not completely unhackable, players can still exploit it to ‘100%’ the minigame, but they will be able to do that always without some really advanced security algorithms, and it’s more secure in the long term than what’s being proposed here.

Using a key for your remotes isn’t the greatest practice, I wouldn’t recommend doing it at all. Exploiters can find out the key and send it to the event. Instead, validate client requests on the server.

i.e. Team Changer
Player clicks GUI button to change to red team, remote event is fired with Red team. Server sees if they are in group A and Red team isn’t full, then changes team if eligible to hop over.

People say don’t trust the client because that’s one of the few strongest methods of keeping an exploiter from running things in your game. So you can’t really push away that statement.

4 Likes

You could try having the client generate a password first thing and fire it to the server. The server can then assume that same password as long as the client stays connected.

local password = math.random()*1231*wait(1) -- or anything math
ReplicatedStorage.Network.Event:FireServer(password)

Of course no other scripts would have access to this password, and this relies on having the variables secured locally.