Game server admin account security

The safest way to make someone a game server admin is by a platform ID - a SteamID64, a Minecraft UUID in online mode, a FiveM licence identifier - written into a file only you can edit, one line per person. The least safe way is a single admin password that everyone types into the game, because it cannot be traced, cannot be taken back from one person, and travels further than you think. Most games offer one or both; your job is to pick the ID-based option wherever it exists, keep the password-based option long, rare and rotated where it does not, and make sure the accounts behind those IDs are themselves hard to steal.

This post is about in-game admin power: who can kick, ban, spawn items and run console commands from inside the game. The panel account that owns the server is a separate, larger target with its own post on two-factor on your panel account, and giving staff panel access without your password is covered in subusers and least privilege.

The three ways games decide who is an admin#

Every game uses one of three models, sometimes two at once.

ID lists are the good case. Admin status follows a platform account, the platform has already authenticated that account, and removing one person means deleting one line. The weak points are the account behind the ID, and games or modes where the ID is not actually verified.

Shared passwords are the bad case. Anyone who knows the password is an admin, the log rarely says which person used it, and removing one person means changing it for everyone. They also leak in predictable ways: screenshots, streams, a pasted message in the wrong Discord channel, a former staff member who still remembers it.

Per-player accounts sit in between. The game has its own username and password system, so admin power belongs to a named account, but those passwords are only as strong as your players make them.

Where admin power lives, game by game#

A few of those need a note.

On Rust, ownerid 76561198012345678 "Name" "reason" and moderatorid grant the two admin levels, and server.writecfg writes them to users.cfg in the server identity's cfg folder. If you forget server.writecfg, the grant disappears at the next restart, which is a surprisingly common reason for "my admin keeps vanishing".

On ARK, typing enablecheats <password> in the in-game console makes you an admin for the session. The SteamIDs listed in AllowedCheaterSteamIDs.txt (in ShooterGame/Saved) get admin without the password. Use the file for staff and keep the password as a long secret that nobody types routinely.

On Palworld, admin is /AdminPassword <password> in chat, and there is no per-player alternative in the vanilla server. The password is the only control you have, so make it long, never use it on stream, and change it whenever someone leaves the team - Palworld admin commands and RCON has the rest.

On 7 Days to Die, serveradmin.xml lives in the save data folder and lists users with a permission level, where 0 is the highest. The XML format changed around version 1.0 to include the platform with the ID, so copy the format from the file your server generated rather than from an old guide.

On FiveM, admin is an ACE grant tied to an identifier:

add_ace group.admin command allowadd_ace group.admin command.quit denyadd_principal identifier.fivem:1234567 group.adminadd_principal identifier.discord:123456789012345678 group.moderator

Prefer license:, fivem: or steam: identifiers. A discord: identifier is only as safe as that person's Discord account, which brings us to the real weak point.

The account behind the ID is the real target#

An ID-based admin list moves the problem rather than removing it. Nobody needs your admin password if they can log in as one of your admins.

Steam accounts are the main target for Source, Rust, Valheim, ARK and 7 Days to Die admins, and they are phished constantly. The common methods are fake trade or tournament sites that show a copy of the Steam login page, "vote for my team" links, and fake "your account has been reported" messages that lead to a login prompt. A staff member who signs in on one of those has handed over your server's admin rights along with their inventory.

What to require of anyone you make an admin:

1. Steam Guard with the mobile authenticator on the account whose ID you list. Email codes are better than nothing; the authenticator is better still.
2. Two-factor on Discord, if Discord roles carry any admin power or if staff coordinate there. A compromised Discord account with a staff role can post a convincing "new admin password" message to your other staff.
3. A unique password for every account involved, from a password manager.
4. No shared accounts. "The admin Steam account" that three people log into is a shared password with extra steps, and it usually lacks two-factor because sharing a code is awkward.

None of this needs to be heavy-handed. Make it part of becoming staff, explain why once, and check it quietly when you promote someone.

Name-based admins and unverified IDs#

Some admin systems can match on a player's name, and a name is whatever the player types into their settings. That turns an admin list into a guessing game.

AMX Mod X on CS 1.6 is the classic case. users.ini accepts a name, an IP or a SteamID, with flags controlling how the entry is checked:

; "name/ip/steamid" "password" "access flags" "account flags""STEAM_0:1:1234567" "" "abcdefghijkmnopqrstu" "ce""Moderator Tom" "a-long-password" "bcdefij" "a"

Account flag c means the identity is a SteamID and e means no password is checked, which is the right combination for a Steam-verified player. A name entry with flag a kicks anyone using that name who does not supply the password. The password is supplied with setinfo _pw "password" in the client console (the field name comes from amx_password_field in amxx.cfg).

That setinfo password has a nasty property: setinfo values are sent to every server the player joins, and any server owner can read them. An admin who stores setinfo _pw in their config and plays on other servers is broadcasting the password. Prefer SteamID entries.

There is a second catch. A SteamID is only trustworthy if the server verified it with Steam. Servers that accept non-Steam clients cannot verify the ID the client claims, and on those servers SteamID admin entries can be impersonated. If your CS 1.6 server accepts non-Steam players, use name-plus-password entries with flag a for admins and keep those passwords private.

Minecraft in offline mode has the same problem. With online-mode=false and no proxy doing authentication, a player's UUID is derived from the name they type, so anyone who joins as your name is an operator. Offline mode is legitimate behind a Velocity or BungeeCord proxy that authenticates players and forwards their identity - but only if the backend servers cannot be reached directly. Minecraft whitelist and permissions covers the safe layout, and Minecraft LuckPerms covers replacing blunt operator status with real permission groups.

Giving staff less than everything#

Most games make admin a single switch, but nearly every admin framework offers levels, and using them limits what one compromised staff account can do.

• Minecraft: op-permission-level in server.properties sets what operators can do, from 1 (bypass spawn protection) to 4 (everything, including /stop). Better still, op nobody but the owner and give moderators a LuckPerms group with exactly the commands they need.
• Rust: moderatorid instead of ownerid for moderators. Owners can manage other admins; moderators cannot.
• SourceMod: flags per person, so a moderator gets kick, ban and chat (bcdj) without RCon (m) or cheats (n). SourceMod admin flags and immunity covers groups and immunity in full.
• FiveM: ACE groups with explicit denies for dangerous commands, as in the example above.
• 7 Days to Die: permission levels in serveradmin.xml, and per-command levels in the same file, so a level-1 moderator can kick but not spawn items.

The principle is the same everywhere: the person who handles chat on Tuesday evenings does not need the commands that can delete the world. Two levels - owner and moderator - is enough for most communities.

Rotation, offboarding and the leaving staff member#

Access you cannot take back cleanly is access you have given away permanently. When someone leaves the team, on good terms or bad, work through the list the same day:

1. Remove their ID from every admin file and every server in the network. A shared admin database (covered in global ban systems for communities) makes this one change instead of five.
2. Change every shared password they knew: the ARK or Palworld admin password, the RCON password, any server join password, any tool login. Yes, all of them, even if they were trusted.
3. Remove their panel subuser access and their Discord staff role.
4. Check the activity log for the last few days of changes made by their account.
5. Look for things they could have left behind: an extra entry in an admin file under a different ID, a scheduled task, a plugin you do not recognise.

That fifth step sounds paranoid until the first time somebody you removed is back with admin under an alt account, because they added the alt's SteamID weeks ago.

Logging what admins do#

Admin power without a record is impossible to supervise and impossible to defend. When a player says a moderator abused them, you want to answer with a log, not a feeling.

• SourceMod logs admin actions to addons/sourcemod/logs, and sm_show_activity controls how admin actions are announced in game.
• Minecraft logs every command run by a player to the server log, and plugins such as CoreProtect record block and container changes.
• Rust, 7 Days to Die and most survival games log console commands and admin actions to the server log.
• The panel keeps a per-server activity log, which covers the people with panel access rather than the people in the game.

Keep those logs long enough to cover a dispute - server logs worth keeping has the retention side - and read them occasionally even when nothing is wrong. Abuse rarely starts with something dramatic.

On RE:NODE, the admin, RCON and database passwords for a new game server are generated per server rather than left at a default, and the panel console works without exposing RCON at all, which takes one shared secret out of circulation. Panel subusers can be given console access without file or billing access, so a staff member who needs to run a command does not need anything else.

Troubleshooting admin access#

My admin rights vanish after a restart (Rust). You ran ownerid but not server.writecfg. Grant again and write the config.

I added myself to ops.json and nothing happened. The server reads ops.json at start; use /op <name> from the console instead, or restart. Check the UUID is the online-mode UUID for your account, not an offline one.

A SourceMod admin is not recognised. The SteamID format in the file does not match what the server sees, or the file has a syntax error. Copy the ID from status, run sm_reloadadmins, and check addons/sourcemod/logs for an error about the file.

Someone who is not staff has admin. Treat it as a compromise until proven otherwise. Remove the entry, change every shared password, check the activity log and the admin files on every server, and read what to do when your server is hacked if you find anything you cannot explain.

FAQ#

Is an admin password safe if it is long enough?

Long passwords resist guessing, but most admin passwords are lost by being shared, not guessed. The problem with a shared password is that you cannot tell who used it or take it back from one person. Use an ID list wherever the game has one.

Should I give my co-owner the same rights as me?

Only if you would be fine with them deleting everything. Give the highest in-game level to as few people as possible, often just the person who pays for the server, and use the moderator level for everyone else.

Can a player fake a SteamID to get admin?

Not on a Steam-authenticated server. The ID is verified with Steam when they connect. It can be faked on servers that accept non-Steam clients and on games or modes that skip platform authentication, such as Minecraft in offline mode without a proxy.

How often should I change the RCON and admin passwords?

Whenever someone who knew them leaves, whenever one might have been seen on stream or in a screenshot, and otherwise a couple of times a year. Rotation that happens only on a calendar misses the moments that actually matter.

Do I need admin rights in game if I have the panel console?

Not for most tasks. The console runs any server command without you being in the game, which is often a safer way for the owner to do occasional admin work.