The problem with qkey that it’s too well-hidden. When re-installing an OS, many people will probably never ask themselves “Tremulous seems to be logging me in automatically, I should probably investigate how and back up whatever is necessary”, and thus lose their qkey files.
4 Likes
Some (hopefully good, and not bad, and/or ugly) ideas:
Move fs_homepath and keys (qkey or RSA) to a more readily available (non-hidden) folder for users, out of .tremulous or %APPDATA%/Tremulous or /Users/[User Name]/Library/Application Support/Tremulous and into either ~/Games/Tremulous/ or %USERPROFILE%\My Games\Tremulous. This would also make screenshots and demos more accessible, and make it easier for players to backup their keys, either manually or through any launcher/utility.
Maybe generate a new ‘qkey’ from a secret keyfile. For instance player selects a file like the image fitmoms05.jpg that they they will never lose, and can later reuse to regenerate the key.
On servers, storing fingerprint for RSA or player’s generated guid from cl_guidServerUniq in admin.dat should be migrated to a DB to prevent admin.dat bloat, maybe using an inter-server (shared) auth system - even using external middle-ware to offload the data if necessary.
Allow a player to generate a one-time-use recovery key they can write down, and if they lose their keys, can enter the secret key to unregister their old name and reassign them their appropriate permissions/flags.
Deprecate rcon passwords and setlevel’ing, and develop an invite-based chain-of-trust system, allowing customization of abilities and permissions (which can also track who is giving out any permissions, and which ones, and when), to be shared securely to individuals via secret codez to be typed using the existing in-game password on connect system, or via links to click on using a trem URI for the player’s computer, eg: trem://myserver.com:30720/<TOPSECRETcode>
2 Likes
There are a lot more issues with the current authentication system. I’m glad that @lamefun brought up authentication in the Evil Geniues Think Tank, this is something that can use a lot of brainstorming. @romdos has started with some good suggestion 
.
Protecting player names might not seem like an important issue, But Tremulous is a very social game for a fast paced shooter (while camping turrets or corners, you can’t help but get to know your fellow teammates 
). In some cases a player impersonation might be done as a well intended prank. However, impersonations can also used for malicious purposes, such as malicious trolling, discrediting, gaining admin powers someone isn’t suppose to have, or phishing. To say the least, things like that can get in the way of enjoying the game.
I have seen all of the issues, that I mention in the “Problems” section of this post below, first hand, and they have been issues in Trem since its beginning. Being a game server operator on some popular servers over the past few years, I have seen a lot of those issues occur almost daily, Additionally, I have even had problems with an abusive game server, whose administration I’m not a member of, relatively recently with impersonation (among many other issues), I don’t connect at all to that server anymore.
But this is not the place to make accusations nor point fingers, and I ask that others refrain from making accusations as well, even if justified and backed up with evidence, that will only distract from the usefulness of this discussion. But what would be very productive is elaborating on the discussed issues or discussing additional related issues, without referring to any specific individual/group/server/project, so that we can better understand what needs to be fixed from a technical perspective. Especially don’t hesitate to chime in with proposed possible solutions to any, some, or all of the discussed issues, even if it might seem crazy, that is one of the main purposes this category is for after all .
Abusive players/admins/servers come and go, and there will be more if we are successful in reviving Tremulous, it is just a fact that they are hazards of of the internet, so fixing the issues of authentication needs to be a top priority. Don’t get me wrong, most of the current Tremulous player base are decent people, I have a lot of friends here, and I love the community, but it only takes a few to be very disruptive if vulnerabilities permit them to.
The Current System:
-
The client generates a pseudo random key that is stored in a file called a
qkey. -
When you connect to a server, your qkey, the server’s ip address, and the server’s port are all used to generate a unique hexadecimal identifier called a
GUID. This ensures that even though a given server would know your GUID for that server, it can’t be used by anyone with access to the GUIDs saved on that server to impersonate your registrations on other servers (older clients can have the issue of non-unique “GUIDs” and that is a serious problem). -
When you register your player name on a server (or when an admin uses setlevel on you), an account is saved in a plain text file named
admin.dat, that includes at least your player name, your GUID for that server, your “admin level”, and any additional “admin flags” that might be included for you that your “admin level” alone doesn’t grant (other information can be stored in your account on modded servers like the last time you were seen, also the admin.dat file contains ban information).
- When you register a name, authentication isn’t case sensitive (so the same name with different letters capitalized is still considered the same name in authentication), also different color combinations is still treated as the same name.
Problems:
In addition to the potential problem that @lamefun mentioned of potentially losing your qkey perhaps by accidentally deleting it, or having a new installation and not transferring your qkey because you don’t know how (or don’t even know that you are suppose to), or maybe you no longer have access to your qkey and didn’t back it up (like maybe your harddrive died), here are some other fundemental problems:
-
You need to register separately for each server, even if a single server owner owns multiple servers, and even if a single server owner has multiple servers on a single machine (each port can only be used by one game server).
-
If a game server moves, changing its ip address and/or port, all of the registrations of everyone who registered on that server are rendered useless, since even for players who are using the same qkey, their GUIDs would be different.
-
It is extremely unlikely for others to obtain your qkey, unless you give it to them. But I have seen that happen a couple of times though, like if someone shared their tremulous home directory including their qkey file, perhaps to seek help with a technical problem. Never share your qkey with anyone. Even developers never have to see it to help you.
-
It is possible to register names that look very similar to other registered names for impersonation purposes, for example using
Ior1orlas replacements to each other, or including additional/substitute punctuation in a non-obvious way, or having different configurations of a/some clan tags. -
This system puts a lot of burden on players to maintain their registration(s), as well as a lot of burden good admins to maintain/verify registrations and in addressing instances of impersonations.
-
Within the scope of an individual server, it is very easy for an abusive admin with just setlevel to facilitate impersonation (it is even easier for someone with access to admin.dat). That can happen on a decent game server, and a good server owner would appropriately address admin abuse if is brought to his or her attention. However, if a given server knowingly tolerates or even encourages such abusive behavior then even reporting an abusive admin is a fruitless task.
Some Possible Solutions:
-
We do have basic support in the 1.3 client and server for RSA Key authentication ( as described in this article RSA (cryptosystem) - Wikipedia ), however it is untested, and likely needs more work. RSA key authentication would address some of the above mentioned issues. Unlike the current GUID, your public key for a given server doesn’t depend on the ip address nor port of that server. This means that a game server can move and keep all of its prior registrations. If combined with database support, a server owner could have a “Game Server Group” where multiple game servers would share the same authentication accounts, so that creating and maintaining such accounts can be done from any server within that group for the entire group. However, within a given game server group, an abusive admin with enough power can still take advantage of such a system.
-
I believe the best overall approach is to have a global authentication system for the game that is independent from individual game servers and game server groups. So that you just need to register once, and then you are registered for all game servers. Are there any recommendations for existing good global authentication systems/models we can use for this?
-
If such a system was tied to a website, you can have your in-game account synced with a website/forum account. This also allows for other ways of signing in, such as optionally making use of OpenID or something like that (imagine being able to authenticate in-game with a steam account, or a github account, or a google account, etc).
-
With global authentication we can also have reliable global stats.
-
Global authentication would also work very well with a related system of global chat (allowing players to be able to communicate with other players between any server, and from the client’s main menu, and from a website, and even from a third party standalone chat client. Many other benefits comes from “proper” global chat, such as being able to leave persistent messages to friends that are offline, much much much better privacy in private message, creating custom channels for coordinating things like trem projects, or clans.
-
A lot of burden would be relieved from individual game server administrations. Making administrating an active server that much less difficult and straining.
-
Global authentication would address a lot of vulnerabilities from malicious admins/servers.
-
-
Regarding the problem of clan tag configurations being utilized to facilitate player impersonations. What if your player name and clan tag authentications were separate? Have it so that you could not use a clan tag in your name, but clans as a whole would register globally, and could register their own clan tags/configurations, and the clan tags would only be shown with players who register as members of a/some given clan(s). It should be visually clear what is the actual clan tag, and what is the actual player’s name. This would also have the additional benefit of addressing the related and common problem of clan membership impersonations.
1 Like