PureAuth

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 o