Offline-mode servers (online-mode=false): risks and protection

online-mode in server.properties defaults to true: the server only lets in players whose account Mojang's servers have verified. With false there's no check at all — the server trusts whatever name the client sends. That lets in players without a paid account, and along with them anyone who claims your name.

What changes with online-mode=false#

The main risk: someone else's name#

Since the UUID comes from the name, whoever joins as Admin gets the same UUID as the real admin. And with it, their inventory, their homes, their permission group and their OP from ops.json. Without an auth plugin this isn't a vulnerability, it's an open door.

The Minecraft Wiki says it plainly: with online-mode=false, attackers with fake accounts can connect. Protection comes in three layers: authentication locks each name behind a password, permissions apply only after login, and bots are cut off before they flood the server.

An auth plugin is the bare minimum#

An auth plugin asks a player to set a password on first join (/register) and to enter it afterwards (/login). Until then the player can't move, place blocks, type commands or use the inventory. A common choice is AuthMe Reloaded (GPL-3.0): separate builds for Paper, Spigot and Folia, proxy plugins for BungeeCord and Velocity, storage in MySQL, MariaDB, PostgreSQL or SQLite. Other auth plugins exist too — AuthMe can import accounts from LibreLogin, nLogin, LimboAuth and a few more.

1. 1

   Install the auth plugin

   Like any plugin — the jar into plugins/ and a restart; details in how to install a plugin. On a network, pick the build that fits your setup: AuthMe has separate proxy plugins.

2. 2

   Choose storage

   SQLite is enough for one server. With several servers, or if you link accounts to a website, use MySQL or MariaDB. Make sure the account database is in your backups.

3. 3

   Lock staff accounts first

   Register admin and moderator names before you open the server, with long unique passwords. AuthMe supports two-factor authentication and can tie a name to an IP address (restricted users) — worth doing for every account with permissions.

4. 4

   Let paid accounts skip the password, if you want

   AuthMe has a premium bypass: a Mojang account holder turns it on with /premium, then gets verified through the session server and never types a password. Without a proxy it needs PacketEvents — which you already have if DGuard protects the server.

Permissions only after login#

Don't hand out OP to staff. OP is tied to the UUID, which means to the name, and it grants everything at once. Give permissions through groups in a permissions plugin — see LuckPerms — and keep the most dangerous commands (/op, permission management, stopping the server) for the console.

Check the plugins that do something on join: grant flight or a game mode, hand out items, teleport. An auth plugin blocks what the player does, not what other plugins do. If such a plugin fires before /login, whoever joined under someone else's name gets the perk.

Servers behind a proxy are a different story#

On a Velocity network, the Paper game servers always run with online-mode=false — and that's not an “offline server”. The proxy verifies the player and passes the UUID and other player data to the servers via modern forwarding: in config/paper-global.yml you enable proxies.velocity.enabled and set secret and online-mode to match the proxy. The proxy itself can still require paid accounts.

But such a server's port must not be left open. Velocity's documentation warns that anyone who reaches a game server around the proxy can impersonate any player, and that modern forwarding is not a replacement for a firewall. Only the proxy's port faces the outside — more in IP and port and Velocity setup.

Bots and ban evasion#

Without Mojang's check, joining under a thousand names costs nothing. That's why offline-mode servers get hit by bots more: join floods, chat spam, mass account registration. What helps:

• The auth plugin's built-in AntiBot (AuthMe Reloaded has one).
• connection-throttle in bukkit.yml — the delay between connections from one IP, 4000 ms by default.
• An anti-bot on the proxy and your host's DDoS protection — options are covered in bots and DDoS.

The same ease works against bans: a cheater banned by name simply joins under a new one. An IP ban (/ban-ip) helps only partly — IPs change. So cheaters have to be caught fast, and again on every new name.

Anticheat on an offline-mode server#

Authentication protects the name, not the world or the fight. KillAura, Fly, Scaffold or Nuker work the same on a paid and an unpaid client, and they have to be caught the same way — by behaviour and packets, not by account.

That's exactly what DGuard checks, so the account type doesn't matter to it: every client goes through the same checks on every front — combat, movement, building, inventory, packets. A new name doesn't make a cheater invisible: on the new account the same checks catch them. How DGuard's checks compare with other anticheats — on the home page.

FAQ#