Authentication

Login & Register

Players must authenticate before they can interact with the server. The flow depends on whether they have an account:

New players

New players see a title, action bar, and boss bar countdown prompting them to register:

/register <password> <confirm>

The password is validated against configurable rules:

• Length — Between min-password-length and max-password-length
• Strength — If require-strong-password: true, must contain uppercase + lowercase + number
• Match — Both fields must be identical
• Not a common password — password.refuse-common checks the chosen password against passwords.txt, beside the configuration, one per line and created on first run with a starter set. Emptying the file disables the check. Nothing is sent anywhere: length and character-class rules describe the shape of a password, a breach list describes whether it is already known — which is what actually gets accounts taken over

Passwords are hashed with PBKDF2-HMAC-SHA256, 210 000 iterations, with a 16-byte per-account random salt. Verification uses constant-time comparison to prevent timing attacks.

pbkdf2$210000$<saltBase64>$<hashBase64>

The iteration count is the point: a fast hash such as a single round of SHA-256 leaves a leaked database crackable on a GPU in minutes, salt or no salt. PBKDF2 ships with the JDK, so this costs no extra dependency.

Changing or resetting a password invalidates every existing session for that account, on every server.

Returning players

/login <password>

After successful login, the player is shown their last login date and IP (if show-last-login: true).

Failed attempts

After max-login-attempts failed attempts, the player is kicked. If IP rate limiting is enabled, the IP may be temporarily banned after too many failures across all accounts.

Titles, boss bar and action bar

The texts a player sees before authenticating live in lang/<code>.yml, so they follow the language setting in XCore like everything else:

Whether each one is shown at all, its timings and the boss bar colour stay in config.yml under login-title, login-bossbar and login-actionbar — those are not language.

Sessions

Sessions allow players to reconnect without re-entering their password within a configurable timeout.

• A session is created after each successful authentication (login, register, premium, bedrock)
• Sessions are stored in the xlogin_sessions database table (UUID + IP + timestamp)
• On join, XLogin checks for a valid session matching the player's UUID and IP
• Expired sessions are purged automatically every 10 minutes

# Session timeout in minutes (0 = disabled)
session-timeout: 30

Player Restrictions

While unauthenticated, players are completely locked down:

Join messages are withheld until authentication. Quit messages are hidden if the player never logged in.