Making games more secure

Help and Feedback Scripting Support
#21

I wouldn’t suggest using a password to secure your remotes. If you store the password on the client any exploiter can easily see this value. If you want your remotes to be secure just make sure the server does all of the work.

Generally only user input or actions should be sent to the server. You shouldn’t give the client the ability to do anything even if you believe it’s secure because security like this will ONLY slow the exploiter down with no extra benefit.

Anything you can do in your localscripts an exploiter can also do.

3 Likes
#22

they can view the source of the localscript?

that is why i made password system.

2 Likes
#23

yes, they can

They can see everything you can see in play solo + other things (e.g. things parented to nil)

3 Likes
#24

But yes, if this password is stored anywhere on the client your entire “security” is moot.

@DevOfLua Do not use passwords. Use a list of people that you control.

4 Likes
#25

Yes they can see the source of the localscript. Roblox does attempt to prevent this but essentially it has the same effect as obfuscation.

3 Likes
#26

An exploiter can view anything that is on the client, as well as anything visible to the client (Workspace, ReplicatedStorage, etc…)

They cannot see services that are only accessed via the server however. This includes ServerScriptService, ServerStorage, etc…

The exploiter can view the source code of your modules (that are in a service view-able by the client) as well as your localscripts. As I stated above.

Passwords for admin events are extremely insecure and will result in your events being abused!

5 Likes
#27

#1 rule about developing a game is never trust the clients input, always sanitize and check input if you have to take client input. This is was a major problem in Phantom Forces, In fact I’m currently working with the developers in StyLiS on sanitizing and removing trust that did and could potentially cause problems.

6 Likes
#28

A Exploiter can use a Remote Spy, it can see any remote that’s being fired and the variables that are going through, therefore the Security Key.

I’ve tried this before in my previous games and it didn’t take long for an Exploiter to figure out my Security Keys and get around them. Since then, I’ve moved to strong server verification which makes it harder to Exploit, it is possible, but not by most.

2 Likes
#29

can you tell me better way to secure it then?

1 Like
#30

You can’t secure this method.
Don’t use this method.
Don’t use passwords.

4 Likes
#31

I don’t know why you’re using a password when Roblox supplies you with a better security measure. NodeSupport already stated this, so I’ll just expand off his answer.

local admins = {
    [22225270] = true; -- my id
    [37177731] = true; -- maybe your id (too lazy to check)
    [2] = true; -- even john doe himself
}
yourEvent.OnServerEvent:Connect(function(plr)
    if admins[plr.UserId] then
        print(plr, "is an admin")
    else
        print(plr, "is not an admin!")
    end
end)

As far as I know, it’s pretty difficult if not impossible to spoof the Player argument, since the server has access to everyone’s IP addresses and most likely uses that.

4 Likes
#32

Your index won’t work, replace:

{
12345,
202020,
-- ...
}

with

{
[12345] = true,
[202020] = true,
-- etc
}

(Indent of course, I’m just on mobile)

5 Likes
#33

forgot about that, good catch

2 Likes
#34

Background: You can’t always trust the client to do the right thing and sanity checks are the easiest ways to secure your remotes mechanic wise. For example if someone’s 1000 studs away from another person doing melee damage, your server should be able to ignore that sort of call and possibly kick the person responsible depending on the circumstances. There are many theories on how to secure your game but by far just predicting possible problems may help you in the long run.

Answer: In this circumstance, having a table of “Admins” in the server script and ignoring anyone else who says the password may help you as others have demonstrated.

2 Likes
#35

What you’re doing (a password for remotes) is a type of practice called “security through obscurity”. I’d argue that it’s not true security (blah blah blah someone’s going to retort grumble grumble). Ideally what you want to do is have your server do sanity checks and validations on its end when a remote is fired, rather than having the client send the server a “password”. This is not secure.

The ultimate goal in security should be to make your server as secure as possible with as little leverage points for exploited clients to take advantage of. And please do not bother trying to make the client secure, you aren’t going to get far with that. A client owns their device, they can do as they please with it.

2 Likes
#36

I’ve heard of people just kicking the client from the game when a RemoteEvent request is even slightly out of correct parameters.

2 Likes
#37

Didn’t think about that one, could be a good one.
I’ve personally got a pretty good trap for the Exploiters that play my game…
I’ve set up fake remotes, that when are fired they ban the players - they are not used by anything.

4 Likes
#38

That’s pretty redundant. It bans the exploiter yes, but now it’s known that it is a fake remote & that fake remotes exist

2 Likes
#39

I change it over time.

2 Likes
#40

Wow, I have never heard of that solution! so clever!

I will definitely think about using this

2 Likes