I like the idea behind UrT HD's Passport system meant to prevent cheating, since the only viable way to handle that is making players establish an online identity which they can then lose for cheating, while keeping it reasonably hard and time-consuming to register multiple times, which, as I understand, is what the system is supposed to do.
However, personally I would never accept an anti-cheating system that runs on my machine as a "black box" and takes the control away from me. I run UrT specifically because it uses an engine which is open for everyone to see and fix, and I can be assured it doesn't do anything besides what the code says.
Still, an online identity system would be a welcome addition to our beloved, open Urban Terror 4.1. Here are two different ideas, one easier and one designed to be more robust but requiring changes in the client and (possibly) server code. I'm posting them here because I'm not a good coder, but having them implemented could relieve some of the issues that game server administrators are currently facing without closing down the game engine source.
A) Have B3 implement identity checking. If it has access to GUIDs sent by the clients, it can compare them to a central authoritative database for a given nickname. In this case, the database needs to hold the plaintext (in this case, users' qkeys) and respond with a hashed value. Nicknames have to be constant, too.
Example: B3 connects to the authority and requests a GUID of user "Boulder" for game server at dswp.de:22222 → authority generates the hash according to the GUID algorithm and sends it back → user is kicked if it does not match or if an entry was not found at all.
Benefits: easy, non-intrusive implementation; compatibility with all clients; friendly error message on kick that instructs you how to register.
Issues: single authority to be entrusted with your qkey; single point of network failure (as the qkey server cannot be replicated to third parties easily); users need to take the qkey with them; unchanging nicks (but a global alias system can easily be made); vulnerable to replay attacks if the client's network is sniffed; still allows a small timeframe of flood attack between join and B3 kick.
B) Have the client send a proof of authority to the server on connection start. I'm thinking about PKI here. The client generates a signature using his private key and authenticates to the server using it. Signed are: nickname, server address/port and a random string generated by the server (say, an UUID) to prevent replay attacks. The server verifies the signature using a public key stored on an authoritative server, which can be replicated as the data is non-confidential - only integrity, not privacy, has to be maintained across the network.
Benefits: resilient; secure from network attacks; mobility support if required (encrypted privkey in the "cloud" that the client gets via HTTP?).
Issues: still need to manage account registrations in a sensible way. Feel free to point out anything else.
I see solution A) as a stop-gap measure really, but could still be a breakthrough in fighting cheating in UrT - in fact, a complete game-changer.
Now, who wants to implement a B3 (or whatever bot they want to use) module as a proof of concept? :) (Oh, a welcome feature would be banning a client for one day after 20 or so connection attempts without a valid GUID to get rid of the recent spammer)
This post has been edited by thewanderer: 20 September 2011 - 11:25 AM