Elytra icon indicating copy to clipboard operation
Elytra copied to clipboard

Simultaneous premium/cracked support

Open WinX64 opened this issue 5 years ago • 0 comments

A brief contextualization

As we all know, the vanilla server has two modes of user authentication: Offline and Online. In offline mode, the server will skip this verification and let anyone connect. In online mode, the client/server will both make validations with Mojang's session server to ensure that the user connecting is who it's claiming to be, essentially limiting access to the server to those who bought the game.

In a simplified manner, the process of authentication first starts with the client positing a request to the session server with its access token (received from logging in with their original accounts), selected profile and the hashed id of the server (composed of its public key and symmetric encryption key used by the client/server) it's trying to connect to. After that, the server sends a request with the user's name and same hashed id to verify that the user is specifically trying to connect to it, and not another server. If all goes well, the client is allowed to log-in. Moreover, this process also enables point-to-point encryption between client and server, further securing the connection.

The current problem

In the vanilla implementation, the client will automatically disconnect from the server during the process if it sends an invalid request to the session server. This factor ends the authentication process early, and prevents it from continuing in the case the player's session is not valid. While not a problem by itself, it makes impossible to servers to allow both cracked and premium members to connect, while still being able to differentiate between the two. image

Numerous attempts on a solution for this problem exist, but most of them end up introducing some kind of inconvenience for the player connecting.

One could perform the authentication process normally, kick players with an invalid session, but allow them to connect on the next attempt while marking them as cracked. While this seems a good solution, it not only makes so that cracked players have to login twice, it also prevents premium accounts from successfully joining in case they tried to log in with an invalid session previously.

The proposed solution

Considering that, when coming from a single point of entry, it is impossible to classify clients as premium/cracked while still letting them connect at the same time, a solution using multiple points of entry is proposed. The server would have two points of entry, one for clients desiring to join with premium accounts, and one for users with cracked accounts.

While there're several ways to create these points of entry, such as two physical server sockets, the proposed solutions makes use of the Server Address field in the Handshake packet. When connecting to a server, the client will send the unresolved address of the server in the handshake packet, which the server can use to make all sorts of decisions. In our case, it will be deciding whether the player wants to log in with a premium account or a cracked one, creating our two entry points.

The server would be configurable to allow the selection of the authentication method based on the address used to connect (e.g.: premium.myserver.com for normal authentication, and cracked.myserver.com for cracked accounts). The premium route would follow the normal authentication method, with only users with valid sessions being able to connect, while the cracked route would simply allow anyone to join, no questions asked. Using the same mechanism that the vanilla server uses, users would be differentiated by the version of their UUIDs, with premium players having version 4 ones returned by the session server, and cracked players having version 3 ones hashed from their names.

This system would of course, be completely optional, with server owners being able to choose between it, and the common online/offline operation modes.

Issues to be addressed

Even though each player would be uniquely identifiable by their UUID, some problems arise when users with identical names are both connected (one premium and one cracked).

Name clash

Even in the most recent versions, some of the game mechanics are not structured to allow duplicate entries, such as scoreboards.

Identification by name

To avoid confusion and misidentifying players, a way to differentiate between them would be necessary for text based mechanisms (Chat, Commands, etc).

WinX64 avatar Apr 29 '20 20:04 WinX64