PureAuth 6.3.1

Authentication and sessions

• Reconnect sessions require matching IP and identity, an unexpired lifetime and current account security settings. Legacy session records cannot grant automatic access.
• Password, PIN, 2FA and recovery changes invalidate previous trust. Administrative changes and password recovery require fresh authentication; an owner changing their own settings may retain the current connection.
• Active accounts are checked periodically so a security change on another backend cannot leave old access active indefinitely.
• The connection deadline covers password login, PIN, 2FA and mandatory Admin Guard setup. Closing a GUI or entering another stage does not remove the deadline.

Proxy synchronization and Redis

• Fixed the PIN window remaining open after an authenticated player switches from the lobby to another backend. Valid synchronization closes the required login window without marking login as interrupted; delayed window opening or an earlier PIN result cannot bring it back.

• Streamlined completion of valid synchronization while retaining signature, security freshness, account-lock, Fair Play and mandatory Admin Guard checks. Voluntary PIN setup and change windows remain separate operations.

• Backend login synchronization now requires signed confirmations and the same shared secret on every backend and proxy.

• Confirmations are tied to the player, current connection, current account security settings and a short validity period. Old, replayed and unsigned messages cannot grant access.

• Improved initialization and valid synchronization handling so a signed response is not blocked by concurrent player-join preparation.

• Improved username reservation maintenance: abandoned connection attempts are not renewed indefinitely, and rejected duplicates cannot release the real player's reservation.

• Reservation ownership is checked again when a connection completes. An unavailable required Redis or database denies admission instead of bypassing protection.

• Improved Velocity YAML configuration handling and cached editable messages on both proxies.

Recovery

• Recovery failures and penalty history survive reconnects and restarts. Stages share history with incorrect-login penalties.
• Password recovery removes a forgotten PIN, revokes previous sessions and requires reconnection. Existing 2FA remains required.
• A previously verified answer cannot overwrite a newer security change. Password replacement and PIN removal are one operation; a failed write does not announce success.
• Administrative unlock also clears the recovery-answer failure counter.

TOTP, backup codes and Admin Guard

• Fixed an intermittent disconnect immediately after the owner correctly removed 2FA. External security resets and account locks still revoke access.
• New TOTP secrets provide 160 bits; existing compatible secrets remain supported.
• Strengthened secret and six-digit code validation while retaining standard 30-second TOTP app windows.
• Enabling 2FA stores the secret, enabled state and entire backup-code set together. Concurrent or stale updates cannot overwrite newer security settings.
• Backup-code recovery can succeed only once even with simultaneous requests across instances. It disables the previous 2FA setup and invalidates its entire previous code set.
• Admin Guard withholds full authentication until required 2FA has been correctly confirmed and saved.
• Wrong codes and failed writes cannot release protection. The ordinary removal command cannot disable mandatory 2FA.
• Backup recovery by an already authenticated administrator restricts the account again until a new mandatory 2FA setup is complete.

Registration and persistence

• Per-IP limits and account creation are checked atomically in the shared database. Simultaneous registrations cannot bypass the limit through concurrent reads.
• Player responses distinguish an IP limit, an existing account and a storage failure.
• Enforced BCrypt's 72-byte UTF-8 input limit to prevent silent truncation of overlong values.
• Failed and stale security writes cannot announce success or grant authentication.

Performance and spam limits

• Fixed waiting for an earlier PIN attempt after valid synchronization: an obsolete attempt no longer holds up new commands. Other limits and protection against parallel authentication attempts remain effective.

• Bounded database, cryptography and network work queues. Saturation does not move expensive work onto the server's main thread.

• Each player can perform one authentication operation at a time; rapidly repeated commands do not multiply concurrent attempts.

• Added performance.request_interval_ms, defaulting to 250 ms. Thread counts, queue sizes and this interval require a full restart.

• Disconnecting cancels queued work for that connection. Old callbacks cannot erase a newer connection's request state.

• Expensive administrative operations and auditing run outside the main thread. Improved overload handling and rate-limited repeated warnings.

• Limited pending Discord webhooks to 16, with a 5-second request timeout. Excess notifications are dropped; webhooks are not guaranteed event storage.

• Added missing Discord notifications for registration, Premium enable/disable and successful module startup. Account-change events follow successful saves; rejected attempts do not announce success. Category switches and delivery limits remain effective.

• Added editable English and Polish authentication_wait and authentication_busy messages.

Visibility and pre-login protection

• Fixed inventory dragging during Fair Play Guard inspections when inventory restrictions are enabled. Both clicks and dragging are restricted according to configuration and inspection state.
• Inventories remain on players during Ghost Mode instead of being cleared and restored from a second item copy.
• Fixed visibility for players joining in different orders and restoration of previous collision and blindness state.
• Expanded pre-login restrictions to attacks/projectiles, pickups, entity interactions, inventory dragging, hand swaps, portals, consumption and mounting.
• The required PIN GUI remains available for authentication without unlocking other world interactions.

Command completion

• Fixed missing TAB subcommand suggestions for /pureauth and its /pa alias.
• Suggestions respect permissions and the typed prefix without case sensitivity. Location and Fair Play arguments are completed, with visible online player names where a command expects a player.
• Password/PIN fields, unknown commands and missing permissions no longer fall back to player-name suggestions. The console-only stats command is suggested only to the console.

Configuration, messages and logs

• Fixed exposure of repeated passwords/PINs in extra arguments on malformed administrative commands: every argument from the secret position onward is redacted.
• Fixed acceptance of empty/invalid CAPTCHA alphabets and invalid lengths. With CAPTCHA enabled, invalid settings are rejected at startup/reload; rejected reloads retain the previous configuration.
• Messages load during initialization/reload; missing entries do not repeatedly read files while handling players.
• Reload also refreshes duplicate-name rejection text. Invalid YAML retains the previous working message set and reports an error without printing private file contents.
• Restart-only settings are not misleadingly switched by /pureauth reload.
• Suppressed standard Paper echoes containing full commands with passwords, PINs and recovery codes. Preserved the administrative audit with sensitive arguments redacted.
• Failed security initialization keeps new player admission denied.

Backups and compatibility

• SQLite produces a consistent snapshot; MySQL/MariaDB exports preserve every account field, Unicode, quotes, backslashes and control characters under different SQL modes.
• A finished backup appears only after the write completes. Failure neither replaces older copies nor starts rotation.
• Concurrent requests cannot overlap backups. Rotation retains at least one PureAuth backup and ignores unrelated files; on POSIX, new backup access is restricted to the owner.
• The Paper module supports Minecraft 26.2.x and 26.3; both ranges were checked on real Paper servers with protocol clients, including Velocity and BungeeCord paths.

Upgrade

Stop the network, back up data, replace every module and configure the same network.sync.shared_secret on proxies and backends with network.sync.enabled: true. Synchronization may remain disabled on a standalone server. Keep the account database and merge configuration settings. Full feature and secret instructions: PureAuth-6.3.1-Wiki-EN.md.