RFC: Automatic Login

Tejdxa · 17 January 2025 05:22

The server currently uses something dubbed “UUID logins” to automatically login players when joining the server. UUID logins aren’t really secure, especially for players playing on servers with more nefarious purposes.

I plan to disable the feature completely in the future, but there’s no deadline as of late because there is no clear path forward.

I’ve thought of a few alternatives, and I’m looking for feedback regarding player experience and accessibility.

Approaches

UUUID / U3ID

UUUID is a simple, band-aid fix which involves modding the Terraria client so that each server sees a different UUID. In essense, no nefarious server can steal the client’s UUID and use it on another server.

Practically, UUUID will have no effect on the player experience: players can still join servers normally without having to do anything else. However, its main drawback is that it’s limited to desktop players, as patching mobile clients isn’t as easy.

Browser-Based Logins

Unfortunately, the Terraria client doesn’t provide enough information to uniquely identify players in a confident manner. Therefore, resulting to external applications is an inevitable consequence.

A non-invasive solution to authentication is having the user open a website, such as login.dark-gaming.com, on a browser. This approach supports both desktop and mobile players, but requires more player input when joining the server.

As of writing, I have two ideas on how browser-based authentication can be implemented, although they are not mutually-exclusive.

Approach 1

The first approach requires that users have logged in through login.dark-gaming.com beforehand. After that point, the user may join the server at any point, and will initially not be logged in. The user may then go to login.dark-gaming.com and press a button to authenticate currently active sessions. “Currently active sessions” mean players that are currently connected to the server and (1) on the same IP address as the browser, or (2) with the same name as the account logged into login.dark-gaming.com. This approach can further be extended to allow the user to use their phone to authenticate a session on their PC.

Approach 2

The second approach is specific to Steam players. It largely uses the same mechanisms as the first approach, but instead login.dark-gaming.com presents the user with a button. The button, when pressed, will open a Steam link and instruct Steam to run Terraria and join Dark Gaming in a specific manner. When the player is fully connected, they will already be logged in.

I suspect that this may be extended to Android (Play Store) and iOS (App Store) players, however, I have not explored whether this is possible.

Password-Based Logins

The Penguin Games Server currently uses this approach.

This approach is the simplest, and supports all platforms as well. All users will be prompted for passwords every time they connect to the server.

However, I’d like to avoid this approach because (1) it’s extremely inconvenient and (2) it pushes users to have insecure passwords or ones that are easy to guess.

Considerations

Opt-in and Staff-Only

Most Terraria accounts do not translate to any real monetary value or other real-world profits. Therefore, malicious actors are less likely to target these accounts and more likely to target Google, Microsoft, and other accounts which may be directly linked to valuable information or resources. Thus, adding stricter security measures — for everyone — has a cost which outweighs the gain.

Then, a simpler approach would then be to only disable automatic UUID logins for staff accounts as well as any user that wants to opt-in. When accounts have automatic UUID logins disabled, they will be prompted for their password every time they join the server.

Trusted IPs

Another approach is to require users to have a matching UUID and an IP address which they’ve logged into in the past 90 days (the number is arbitrary).

For example, when a player logs in on a phone connected to a WiFi network, the server will record the IP address of the network. The player may leave whenever, and when they rejoin using the same WiFi network, they will be automatically logged in as before.

This differs with the current approach in two scenarios

The network doesn’t have a static IP address, which is usually the case in densely populated regions such as the Philippines. When this happens, the user needs to log in again.
The user is connecting using mobile data, which lack static IP addresses as well, and users will need to log in again quite often.

Furthermore, the approach may be extended such that the 90 days is “sliding.” In the scenario above, a non-sliding expiration means the user will always be asked for their password again after 90 days. However, a sliding expiration means the user will only be asked for their password again if they haven’t logged in for more than 90 days.

Compromised Users

None of the aforementioned approaches protect against malware stealing login information.

popstarfreas · 17 January 2025 11:02

In terms of risk I would say:

High: staff
Med: elevated permission users such as map builders or anyone with trusted commands
Low: Normal Crew and below

Thoughts on which solution

The client mod is the simplest one for desktop, and I would say that the server would also have to know that the client has this mod to allow a staff login to prevent any accidents.

However, there is the issue of the game updating and that means staff waiting for the updated client. Plus it’s also it’s a bit tricky because to allow mobile to then login you would need another approach as an alternative and that could well complicate things.

So if we implement something perhaps a single solution is best overall.

Browser Approach Modified

So on to browser logins, perhaps a slight modification to your first approach, upon trying to join, if that name is an account that requires it, a code is displayed as part of the status message. In the browser on the appropriate website, they enter the code (can be short, like just a number, mostly just to make sure they don’t authenticate the wrong person) to continue joining the server. With this code, it seems debatable if we would need to require the same IP because the code should be random and perhaps unique to that join attempt at the moment of joining so that it only ever authenticates one attempt. This has the advantage that if done correctly, it could stop anyone from simply joining with that name and preventing the situation where a user can’t join because someone already joined with the same name as a guest.

It is of course inconvenient to have to do it each time but I don’t see a way to avoid that in a single solution.

Enforcement

I would say whatever the approach, we should require staff members to use it. Medium risk users could be dependent on what permissions they have. For everyone else it could be opt in.