我的世界离线模式服务器的安全基石：AuthMe 让用户名冒用失去意义

离线模式服务器的安全基石：AuthMe 让用户名冒用失去意义

离线模式（Offline mode）的 Minecraft 服务器存在一个先天问题：任何人都可以使用任意用户名连接。由于服务器不会连接 Mojang 认证服务，它无法确认连接者是否真的拥有这个账号。只要攻击者知道某位管理员的游戏 ID，就可以改成同样的名字进入服务器，尝试继承对方的权限，这就是常见的“用户名冒用”攻击。

AuthMe 正是为解决这个问题而生。AuthMeReloaded 目前在官方仓库显示拥有 872 个 Star，采用 GPL-3.0 协议，以 Java 编写，最新稳定版本为 6.0.0。项目自早期 AuthMe 延续至今，已经经历了十多年的维护与演进。官方仓库将它称为 Bukkit API 上的身份验证插件，并提供了用户名冒用防护、反机器人、Session Login、图形化登录界面以及多平台支持等功能。官方仓库 和 bStats 统计页面 均可查看项目资料与使用数据。

工作原理

AuthMe 的核心机制很简单：玩家进入服务器后，必须先完成身份验证，未验证期间不能正常游戏。根据配置，玩家可能无法移动、放置方块、执行普通命令，也不能打开或操作物品栏。

第一次进入服务器时，玩家需要注册密码：

/register 密码 确认密码

之后再次进入服务器，则需要登录：

/login 密码

验证成功后，限制才会解除，玩家可以恢复正常游戏。

因此，即使攻击者冒用了管理员的用户名，他也无法仅凭名字获得管理员权限。由于不知道该账号设置的密码，攻击者会被限制在登录状态之外，无法移动或执行管理操作。管理员本人完成登录后，则可以按照服务器的管理流程处理异常连接。

AuthMe 还提供 Session Login。启用后，玩家成功登录时，插件会记录账号与 IP 信息。在 Session 尚未过期且 IP 没有变化的情况下，玩家重新连接时不必再次输入密码。只有更换网络或 Session 超时后，才需要重新验证。对于经常掉线、重连的服务器来说，这项功能能减少重复操作，但管理员仍应根据服务器风险设置合理的有效期。

密码存储安全

AuthMe 不会直接保存玩家输入的明文密码，而是保存密码哈希。当前配置支持 SHA256、ARGON2、BCRYPT、PBKDF2、PBKDF2BASE64 等算法，同时兼容多种旧系统哈希格式。默认配置示例使用 SHA256，但服务器管理员可以根据运行环境和安全需求选择更合适的算法。官方配置文档 和 哈希算法文档 提供了完整列表与配置说明。

其中，ARGON2 是现代密码哈希方案之一，BCRYPT 是使用广泛的自适应哈希算法，PBKDF2 则常用于符合标准要求的密钥派生场景。算法本身并不能替代安全配置，密码长度、服务器权限和数据库访问权限同样重要。

AuthMe 也能读取外部系统中的密码哈希，包括 XFBCRYPT、MYBB、PHPBB、JOOMLA、WORDPRESS、WBB3、WBB4 和 IPB3 等格式。假如 Minecraft 服务器与论坛共用账号系统，AuthMe 可以直接读取论坛数据库中的哈希进行验证。这样一来，玩家在论坛使用的账号密码可以继续用于 Minecraft 登录，迁移过程不必强制所有用户重新注册。

数据库方面，AuthMe 支持 MySQL、MariaDB、PostgreSQL 和 SQLite。缓存机制可以将常用查询结果保存在内存中，减少重复访问数据库的次数。不过，在代理网络或网站联动场景中，缓存是否开启需要按照官方配置说明处理。

反机器人系统

离线模式服务器经常遭遇机器人注册攻击。攻击者可以编写脚本，使用随机用户名批量注册账号，在短时间内制造大量垃圾数据。账号数量快速膨胀不仅会污染数据库，还可能增加登录、注册和数据库写入压力。

AuthMe 内置 AntiBot 系统，可以根据一段时间内的请求数量判断是否出现异常。当连接、登录或注册请求超过设定阈值时，系统可以自动进入 AntiBot 模式，暂时阻止新的注册或限制可疑请求。管理员可以配置检测时间窗口、触发阈值、延迟时间以及 AntiBot 的持续时间，具体数值应根据服务器正常在线人数和登录高峰进行调整。

AuthMe 还支持基于 GeoIP 的国家白名单和黑名单。插件可以使用 MaxMind 的 GeoIP 数据库判断连接者所在国家，管理员则可以选择允许或禁止特定国家的连接。例如，只面向中国玩家开放的服务器，可以将中国设置为允许区域，减少部分海外机器人连接带来的压力。

GeoIP 更适合作为额外过滤层，而不是唯一的安全措施。代理服务器、云主机出口和移动网络都可能导致 IP 地理位置判断出现偏差，因此规则设置仍需要结合实际玩家来源调整。

图形化登录界面

传统 AuthMe 主要通过聊天框接收登录命令，例如 /login password。这种方式对新玩家不够直观，而且玩家输入的内容可能出现在聊天记录中。

新版 AuthMe 提供了 Dialog UI，可以使用图形化对话框完成登录和注册。根据官方说明，Spigot 1.21.6 及以上版本支持对应的图形化流程，Paper 和 Folia 则需要 1.21.11 及以上版本。玩家连接后会看到登录或注册界面，其中包含密码输入框和确认按钮，密码不会像普通聊天命令那样直接出现在聊天窗口中。

Dialog UI 目前分为两种流程。Post-Join 模式会在玩家进入服务器后显示对话框，玩家完成认证前仍会受到限制。Pre-Join 模式仅适用于 Paper 和 Folia，可以在玩家完全加入服务器之前显示登录界面。未验证的玩家不会正常进入游戏世界，从而缩短登录前可能暴露服务器状态的时间。

两种模式可以分别启用，也可以同时启用。对于重视登录阶段安全性的服务器，Pre-Join 模式更适合用作第一道限制；对于需要兼容旧版本或保留恢复账号功能的服务器，Post-Join 模式配置起来更灵活。

Premium Bypass：正版玩家免密登录

Premium Bypass 是 AuthMe 中非常实用的一项功能。启用后，拥有正版 Minecraft 账号的玩家可以跳过密码验证，直接进入服务器。

它并不是简单地根据用户名放行。玩家连接时，AuthMe 会通过加密握手与 Mojang 会话服务器验证身份。只有 Mojang 确认当前连接确实来自对应账号，插件才会允许玩家跳过密码登录。这样可以避免仅凭用户名匹配造成的冒用风险。

这项功能尤其适合混合模式服务器。正版玩家已经完成 Mojang 认证，因此不需要再次输入密码；离线模式玩家无法通过 Mojang 认证，则仍然需要使用 AuthMe 密码登录。两类玩家可以在同一服务器中共存，同时保持不同的安全验证方式。

Premium Bypass 对部署方式有不同要求：

• 直连模式，也就是服务器直接面向玩家并运行在 Offline mode 下，需要安装 PacketEvents 2.x，才能在登录阶段完成身份验证。
• 通过在线代理连接时，Velocity 或 BungeeCord 已经完成 Mojang 认证，后端 AuthMe 可以使用代理转发的已验证身份，通常不需要在后端额外安装 PacketEvents。
• 通过离线代理连接时，需要在代理层安装 authme-velocity 或 authme-bungee，由代理插件完成正版玩家验证并同步认证状态。

因此，Premium Bypass 的安全性取决于完整的部署链路。代理转发、后端在线模式设置、共享密钥和 UUID 传递都必须按照官方文档配置，不能只打开一个开关就认为认证已经完成。

多平台支持

AuthMe 6.0.0 为不同服务端平台提供了独立构建包。安装时应根据服务端类型、Minecraft 版本和 Java 版本选择对应文件。官方 6.0.0 发布说明 列出的主要构建包括：

• AuthMe-*-Spigot-Legacy.jar：适用于 Spigot 1.16 到 1.19，Java 17 及以上。
• AuthMe-*-Spigot-1.21.jar：适用于 Spigot 1.20 到 1.21.x，Java 21 及以上。
• AuthMe-*-Paper.jar：适用于 Paper 1.21 及以上，Java 21 及以上。
• AuthMe-*-Folia.jar：适用于 Folia 1.21 及以上，Java 21 及以上。
• AuthMe-*-Bungee.jar：适用于 BungeeCord 和 Waterfall 代理，Java 21 及以上。
• AuthMe-*-Velocity.jar：适用于 Velocity 3.4 及以上代理，Java 21 及以上。

BungeeCord 和 Velocity 的原生代理插件，是多服网络中的重要架构选择。将认证逻辑放在代理层后，玩家只需要完成一次验证，就可以在多个子服务器之间切换，不必每进入一个子服都重新登录。AuthMe 会在代理与后端之间同步认证状态，并向后端传递已验证的玩家身份信息。

账号迁移和导入

如果服务器之前使用过其他认证插件，AuthMe 也提供了账号导入功能。目前支持 Auth+、LibreLogin、LimboAuth、nLogin、OpeNLogin 和 tiAuth 等来源。

迁移时，原有账号的用户名、UUID 与密码哈希可以按照导入器规则写入 AuthMe 数据库，玩家不必因为更换插件而全部重新注册。不同系统的字段结构和哈希格式并不完全相同，因此正式迁移前仍应备份数据库，并先在测试服务器中验证登录结果。

数据库类型之间也支持转换。例如：

/authme converter sqliteToSql

该命令可以将 SQLite 数据迁移到 MySQL、MariaDB 或 PostgreSQL，适合服务器规模扩大后从本地文件数据库转向独立数据库的场景。

安全细节

AuthMe 的防护重点并不只在 /login 命令本身，玩家完成认证前的整个 Limbo 状态都需要受到限制。

默认情况下，未认证玩家不能自由移动。服务器还可以将玩家传送到出生点，限制聊天和命令，并设置登录、注册超时。物品栏保护需要 PacketEvents 支持，用于阻止玩家在认证前查看或操作物品栏。

玩家在登录前投出的末影珍珠也会被记录，并在成功认证后返还，避免利用认证阶段的实体行为制造异常传送。玩家退出时的位置可以保存，防止登录状态、重连位置和区域限制之间出现不一致。

在更底层的 Limbo 处理中，AuthMe 还可以暂时移除玩家的 OP 状态、飞行能力以及移动速度等属性，完成登录后再恢复。这样做是为了避免玩家在认证前通过状态继承或重连过程触发权限问题。

这些细节看起来零散，却对应着不同的攻击面。玩家即使不能正常移动，也可能尝试打开物品栏、发送特殊数据包、投掷实体或利用重连观察服务器状态。AuthMe 通过限制这些行为，把身份验证阶段从“只禁止输入命令”扩展为完整的受限状态。

AuthMe 解决的是离线模式服务器最直接的安全问题：服务器无法确认用户名背后的真实身份。安装并正确配置后，攻击者不能再仅凭冒用管理员名字就直接获得管理员权限。

对于许多离线模式服务器来说，AuthMe 几乎是基础设施级别的插件。它提供密码验证、Session Login、哈希存储、反机器人、GeoIP 过滤、图形化登录、正版免密和代理同步，覆盖了从单服到多服网络的多种部署场景。

不过，AuthMe 不能替代完整的服务器安全体系。管理员仍应使用高强度密码，减少 OP 权限，保护数据库凭据，正确配置代理转发，并定期备份服务器数据。它能堵住用户名冒用这条入口，但服务器的整体安全仍取决于权限、网络和运维配置。

项目地址：github.com/AuthMe/AuthMeReloaded