im pretty glad about that too... seeing some of the flame wars on certain threads i decided to join in as a peace keeper... mind you some of the guys... god damn they might just go "ooooh.... FUCK OFF GRASHOPPER!!! *gunshots*" not really naming anyone as it hasnt happened yet, but i imagine it will XD
Surprise, surprise, warlovr has become a popular name choice for cheaters on no-login servers. Grrrr....
Any chance of devising a system to reserve warrior names and GUIDs?
Wouldn't be the end of the world if many of us lose our warrior names, but it'd sure be nice if I didn't have to ban warlovr from Rebels servers when the auth server comes on line.
Whatever.
Thanks again for all your efforts on behalf of T2!
I'm with WarLovR on this one... my name is a lot less likely to get stolen, but still this is a valid concern. Someone malicious enough could reg a bunch of other people's names before they get the chance to.
I agree... I think though, that good systems will be run by admins who have methodologies in place to correct this, or allow for disputes using UIDs stored on PCs checked against server logs. There are likely even more sophisticated ways as well.
I agree... I think though, that good systems will be run by admins who have methodologies in place to correct this, or allow for disputes using UIDs stored on PCs checked against server logs. There are likely even more sophisticated ways as well.
There is no way to "unregister" a user after they've already generated a key pair. Unless you come to their house and destroy their private key file...
Either way, once the system is released, I'd bet people would be more worried about reserving their own name as opposed to someone else's. And with the 1 registration per week restriction, that pretty much guarantees you your own name. Unless somebody really, really wants it (more than their own).
One registration per week doesn't mean anything. Change your IP, bam, new account. My IP is dynamic and my internet resets itself about 10 times a day, so I could make 10 accounts every day without doing any extra work at all.
Not that I am going to.
Edit: Unless you mark someone's T2 installation somehow after they register so they can't register again. That could be a good idea. As long as they don't figure out how it's marked and undo it.
I realize you guys just want to be sure you get your name, but keep in mind we're trying to restore functionality, not take control over aspects that the client would normally have free run of. Sure, reserving a name might be nice if you think someone is going to go for it, but it's not really feasible.
Even if we were to deny a player their chosen account name simply because someone said that person wasn't who they said they were, not only would that be a breach of trust, but it would lead to dozens of other such requests with questionable intent.
What I can recommend to you is: Get the patch and create your account as soon as it's out. Most people, even those with malice in mind, will be making their own accounts and trying it out before they do anything else. Unless there's some bad apples, you're probably going to get the name you want just fine.
Unless you mark someone's T2 installation somehow after they register so they can't register again. That could be a good idea. As long as they don't figure out how it's marked and undo it.
That's security by obscurity, which lasts until one person figures it out. In any case... most people don't have such rapidly changing IP addresses.
I'm not going to implement some sort of obscurity to prevent people from registering from the same machine, especially since I want people, who potentially have siblings, to register accounts for use.
The only secrets I plan to keep in this system are the private keys to authentication, updating, and community server delegation. I have kept my design transparent and open to encourage constructive criticism for and confidence in the system I create.
Vsf: I think we've all heard what you want to say. You want some sort of solution that doesn't alter the executable (ignoring the fact that accepting all inbound connections in LAN mode requires one), and you believe that you can effectively mitigate man-in-the-middle attacks without a cryptographically secured endpoint authentication.
I'll concede this: there is a way to do secure endpoint authentication in just TorqueScript with any symmetric cipher (I've personally implemented RC4 in TorqueScript, which is suitable), which would prevent man-in-the-middle attacks on player tokens. But, you are still talking about a cryptographic implementation. A system with this design is a logistical nightmare to manage, and a significant technical burden to your users. While such a design can be secure, asymmetric crypto certificates are a MUCH better route for half a dozen different reasons.
If you are still set on a script based solution, I'd be more than willing to tell you how to build such a system if you have not figured out what I'm talking about by this weekend. You can decide then if you feel that route is acceptable to you, over your pseudo-secure design. While I disagree with your choice, that doesn't mean I'll leave you to the wolves and trolls.
In a sentence: it is not an issue with my design.
[fluff]
Here are all possible attacks,
[fluff]
Lines like this concern me a little. Confidence is good. Overconfidence is weakness. Don't get me wrong, I've been rooting for you from the start and pointing other people to this project, but a split namespace is not good for Tribes 2. Whoever re-implements authentication first had better do it right and do it well.
Here is the attack I'm describing as far as I can tell, your design is vulnerable.
13) Eve really wants Game Server Bob to think she is Player Bob.
so...
Eve starts up her rogue server and loads it up with bots (with non-obvious names) to attract players.
Eve starts her client and waits.
Bob joins Eve's server and sends his signed certificate (bob_e, bob_d, bob_n, bob_guid, bob_name) and a random 64-bit number (let's call it bob_rand64.)
Eve's server passes Bob's certificate and the random number to Eve's client.
Eve's client connects to Bob's server and sends Bob's certificate and random number, emulating step 7.
Bob's server performs step 8 the auth server's signature is correct, because it's Bob's real certificate.
Bob's server performs step 9, appends its random 64-bit number (let's call it serv_rand64) to Bob's, encrypts the resulting 128 bits with Bob's public key (bob_n, bob_e), and sends the result to Eve's client.
Eve's client delivers the server's challenge (the encrypted bob_rand64 + serv_rand64) to her rogue server, which in turn sends the challenge to Bob.
Bob's client believes it's decrypting the challenge for Eve's server, so it dutifully performs step 10 and sends the resulting serv_rand64 to Eve's server.
Eve's server relays the serv_rand64 to her client, which her client then sends to Bob's server.
Bob's server receives the correct serv_rand64, and Eve is now connected to Bob's server with Bob's name.
When everything is said and done, Bob's server thinks it has been talking to Bob the entire time, and Bob's client is unaware that an attack has occurred. As I said, this is an active attack, and difficult to use to target a specific person; however, a griefer may only be interested in impersonating other players to avoid immediate detection and evade bans. For this purpose, connecting as effectively random (but distinct) players is sufficient connecting as someone with a good reputation is merely a bonus. The ability to connect as someone who you are not, even if you don't get to decide exactly who you connect as, seriously weakens the integrity of the entire system.
Unfortunately, I don't have a good solution to offer you (although admittedly, I haven't put much thought into for your design yet, having just seen it.) This problem is the very reason certification authorities exist, and that model doesn't translate terribly well.
And that is why I'm not using a pure TorqueScript auth implementation. It isn't possible to do it with this level of security, since it isn't possible to implement asymmetric crypto in TorqueScript.
I suspect asymmetric crypto is possible, but very probably not worth the effort. You say you've implemented RC4 in TorqueScript, so I'm sure you're well aware of T2's obsession with fabs() and all the problems it presents when you're trying to do math with large (>23-bit) numbers. It's not a road I'm terribly interested in traveling any further down.
I think that I've managed to design something that's as resistant to impersonation as your design (aside from the fact that the password is sent to the master server in the clear, a problem which can be remedied with enough time and patience to fight with TorqueScript), but it suffers from the same MITM problem as your design, and it's not NEARLY as elegant (out of necessity.) With real crypto, you have better tools available to address the problem.
I confess I've only skimmed the latest so if I miss anything big, forgive me. And before I post, I am asking anyone to skip if it will annoy them
***Sloik***, under some systems, yes, other systems no obviously a design thing. I do believe thought that in the end, some people will win, some will lose. It just depends on the system and the people running it. I could just as easily one day tell someone, "sorry, you have to make a new account... I can't tell who is who'. Others I may even ask other admins, if it's important enough, 'hey, can you help me validate this person?'. Either way I think the quick people will win, as you know, and, again, I hope for the kindness of people to kick in (cmon people, dont snicker too much at the funny guy on stage with the tu tu). In the other hand there are a few players I know that as a future system admin, I may reserve their names. I am glad you brought up that point, thank you.
***Thyth*** Yeah, you are right about the concern of altering compiled code. And call me naive (worse has been used) but you have made me think more into it all. For example, someone could say to a game server "I'm Vsf, from this IP with this GUID (which happens to bind my users and information together in SQL on the Auth Server), and that would be hacked if that GUID was found. But (for some, I know you see it Thyth) the idea would be a onetime use auth plan... server gens all auth info when you login via https browser and drops cookie, game client starts and reads it to dynamically create a LAN user as picked by the user (which was stored by server), client gives recent time, recent IP, static GUID and 60 minute use it or lose it temp GUID to game server, game server auths back to auth server, yeah or nae, player gets in or not, would be the idea. I suppose that is a word version of my diagram with some other details.
The way I am thinking, I could use crypto in M$ server side stuff (the auth server can do it C# has all the libs), but in reality the one key is a 64 digit random number only good for 60 minutes (until you pick the cookie up and its read into the game) or 10 or whatever. In this case its not even real crypto, just random (64 hexdec digits). Basically use the number on the top of the pad and throw away. Everyone gets a fresh spared square (I know some of you got that . The server registration would work similar but could better benefit from your idea Thyth since its only a two way handshake instead of three, but known, shared info would work who mentioned the super computer earlier? Either way, during client auth the game server would also have to prove itself to the auth server on handshakes and client checks.
The big problems (for me) are time, the T2 scripting (just not my forte but getting offers) that speak TCP pipe with Auth server (although non-secure httpObject may work with strings Thyth, did you say httpObject was bad or just the ssl version), tcp-pipe talking (again client), then later making it so a person does not need to quit and pick a new server to play on because at first the server list would be http page based, and clicking a link will give you the cookie with the server to connect to as well. Clearly going into better T2 script would be much nicer, but other than that, Id like to eliminate as much T2 internal GUI stuff as possible. The sign up, player creations, teams, player/team affiliations, (at first server lists) and maybe even finer player adjustments could be done on http pages. Hmmmm I do suppose that aligning a server side player storage to game side player profile would be needed, otherwise the storage implications may be trouble based on the server someone picks grrr . Well, I suppose you lose some weapons and gain others now anyway when going server to a new server somethimes
Okay sorry, I was kinda talking to myself toward the end not uncommon. Please forgive my rambling and especially if I stepped on what anyone said.
Here is the attack I'm describing as far as I can tell, your design is vulnerable.
13) Eve really wants Game Server Bob to think she is Player Bob.
so...
Eve starts up her rogue server and loads it up with bots (with non-obvious names) to attract players.
Eve starts her client and waits.
Bob joins Eve's server and sends his signed certificate (bob_e, bob_n, bob_guid, bob_name) and a random 64-bit number (let's call it bob_rand64.)
Eve's server passes Bob's certificate and the random number to Eve's client.
Eve's client connects to Bob's server and sends Bob's certificate and random number, emulating step 7.
Bob's server performs step 8 the auth server's signature is correct, because it's Bob's real certificate.
Bob's server performs step 9, appends its random 64-bit number (let's call it serv_rand64) to Bob's, encrypts the resulting 128 bits with Bob's public key (bob_n, bob_e), and sends the result to Eve's client.
Eve's client delivers the server's challenge (the encrypted bob_rand64 + serv_rand64) to her rogue server, which in turn sends the challenge to Bob.
Bob's client believes it's decrypting the challenge for Eve's server, so it dutifully performs step 10 and sends the resulting serv_rand64 to Eve's server.
Eve's server relays the serv_rand64 to her client, which her client then sends to Bob's server.
Bob's server receives the correct serv_rand64, and Eve is now connected to Bob's server with Bob's name.
When everything is said and done, Bob's server thinks it has been talking to Bob the entire time, and Bob's client is unaware that an attack has occurred. As I said, this is an active attack, and difficult to use to target a specific person; however, a griefer may only be interested in impersonating other players to avoid immediate detection and evade bans. For this purpose, connecting as effectively random (but distinct) players is sufficient connecting as someone with a good reputation is merely a bonus. The ability to connect as someone who you are not, even if you don't get to decide exactly who you connect as, seriously weakens the integrity of the entire system.
Slight nitpick: Bob doesn't send bob_d as part of the cert, but otherwise you're right. Thank you for noticing that. It actually isn't that difficult to fix. Last 32-bits of the challenges can be the client and server IP addresses, inverse-respectively. While the rogue game server would be able to modify Bob's 32-bit address appended to the 64-bit random number, Bob's server would insert a 32-bit address prior to the encryption step that wouldn't match Eve's rogue. When Bob the player gets back the (now 192 bit) encrypted blob and decrypts it, he will notice that neither of the address bits (64 bits in total) are correct, and can terminate the connection.
I guess I didn't think that through all of the way through when I decided that servers shouldn't need to register with the auth server. I'll implement the IP inclusive nonce fix into the scripts, with credit to you for spotting the bug.
I suspect asymmetric crypto is possible, but very probably not worth the effort. You say you've implemented RC4 in TorqueScript, so I'm sure you're well aware of T2's obsession with fabs() and all the problems it presents when you're trying to do math with large (>23-bit) numbers. It's not a road I'm terribly interested in traveling any further down.
Of course it's possible, but impractical. The arithmetic operations provide results that are not consistent with integer arithmetic above 23 bit numbers. I had a lot of fun when I decided to use ~%num instead of (%num * -1) - 1, to save a multiplication, and discovered that while ~0 appears to be -1, the numerical comparison (==) operation fails against a real -1. Someone could implement a safeAdd(), safeSubtract(), safeMultiply(), safeDivide() that uses the bitwise operations to perform arithmetic, but it would be terribly slow, and still limited to 32-bit numbers.
I attempted to go in a related direction several months ago, when I first came up with this project. I went the route of implementing arbitrary sized integers in arrays of 16-bit values. It was too slow to be usable for anything.
RC4 is one of the few "real" ciphers that can be implemented in the game script, since it uses a 256 byte mixer, with 8 bit values in each of them. Its implementation is also really short and simple. It just has known weaknesses that can be addressed by cutting off the first few thousand bytes.
I think that I've managed to design something that's as resistant to impersonation as your design (aside from the fact that the password is sent to the master server in the clear, a problem which can be remedied with enough time and patience to fight with TorqueScript), but it suffers from the same MITM problem as your design, and it's not NEARLY as elegant (out of necessity.) With real crypto, you have better tools available to address the problem.
I'd love to hear your design, and help you do a sanity check for issues like the one you noticed.
Edit: New encrypted blob is 192 bits.. not 160. Go basic arithmetic.
Ack... ack... ack ack... ack ack ack... ackackakcackacka (background music "oooooohhhh weeeeee ahhwhhwhhhwhh weeeeeee, ooooooowwwwwww weeeeeeeee eeeeeeeee") POOOOOOFFFF! Vsf's head becomes a puff of pink, while thinking through all the described crypto points, and listening (for some reason) to Hank Williams(?) yodel while wearing a fishbowl over his head (huh?). Joke aside...
fabs() is the C and C++ Math API function for floating point absolute value.
Oh, and Rain: depending on your design, you may be able to use an interlock protocol to prevent that type of man-in-the-middle attack. It isn't compatible with my design, but the concept may be compatible with yours.
Mike, about fabs(), it's not a C# thing really. There are things in C# I've worked with but in six years, but I've not seen this one. Do you know that it exists in the C# framework? Also, it could be a Java thing that C# calls something else... ahh... I am again reading T's answer... most C# business work is data related, and even then heavy strings... an absolution function of a float (quite a long number) I can see but I'd need to look up the name... it may even be the same... I can even see it comming up in calcuclating currency, or science, but if you are writing asp.net pages that do allot of dataset or datatable display, especialy non-numerical (strings) you are not gonna see this allot. C and C++ though, from what I know from others, is used more heavy in point, vector, etc operations to build interfaces, and unless a lib is used. m$ abstract us from allot to some versions of RAD business operations (again, not even necessarily financial). I had someone ask which SAX lib is the best and I could not answer... unless you replace the MS XML interpereters (such as XML SPY) then you have the two main versions to work with.
It's kind of odd really... when you interview you can pick out the previous hard core C++'ers. Sometimes it even comes along with scorn. The question may be, would you prefer (as a business developer) to work in systems that well over 60% of the world developes in, or not, when it comes to your pay and what is predominenet in your local? For example, I'm quite sure silicone vally is far heavier Java than allot of Florida. My locale is HEAVY M$, light Java, but most business work is not in C++ any more.
I did just think of this though... if I'd seen the name "abs()", that would be a giveaway. But even then, what tossed me was the fact that (I am fairly sure) in the .NET lib, abs() works with all numerical types. So I was unsure if fabs() was like a blob or whatnot.
It actually isn't that difficult to fix. Last 32-bits of the challenges can be the client and server IP addresses, inverse-respectively. While the rogue game server would be able to modify Bob's 32-bit address appended to the 64-bit random number, Bob's server would insert a 32-bit address prior to the encryption step that wouldn't match Eve's rogue. When Bob the player gets back the (now 192 bit) encrypted blob and decrypts it, he will notice that neither of the address bits (64 bits in total) are correct, and can terminate the connection.
This sounds nice in theory, but NAT makes this a lot more complicated. Once again, Ruby will give you better tools to solve the problem (like access to the full BSD socket API), but there are some stumbling points. As far as I know, neither the server or the client can get its own IP address via TorqueScript, and behind NAT the OS may not even know its outside IP address (the one the server will see.) Similarly, on systems with more than one IP address (which is much more likely on the server side, of course) it can be difficult to determine which IP address the OS will use for the connection. Combining the two, if you have a dedicated server running on a PC behind NAT (with the appropriate ports forwarded on the router for the public to connect), the connection to your own server will be on the inside IP, and the server will need to figure that out for the challenge to work.
There are ways to allow the client to discover its own IP, of course, but that still won't solve the internal server problem or reliably cope with NAT with multiple external IPs. Since NAT with multiple external IPs is pretty uncommon (especially on a connection where hosting/playing a game would be sane), we could probably simply not support it, but any of these problems will be a pain to debug and a pain to explain to users expecting everything to Just Work.
I guess I didn't think that through all of the way through when I decided that servers shouldn't need to register with the auth server. I'll implement the IP inclusive nonce fix into the scripts, with credit to you for spotting the bug.
Thanks!
I'd love to hear your design, and help you do a sanity check for issues like the one you noticed.
Alright, let me try to make something presentable out of my notes... No perty pictures, sorry. :P All the time figures are tweakables, of course.
Stage 0: Client login
The client proves its identity to the master by providing a username and password. The only real purpose of <clientPrivateToken> is to avoid sending the username/password over the wire any more than is absolutely necessary.
CLIENT → MASTER: login <username> <password>
If the username and password are okay, the master generates a random authentication token, <clientPrivateToken>, which expires after 6 hours and is replaced by a new token on the next login. All authentication tokens are blocks of opaque, random data long enough to prevent brute-force attacks.
CLIENT ← MASTER: authtoken <clientPrivateToken>
Upon connection to a server... Stage 1: Client provides its identity to the master.
SERVER → CLIENT: authsupported
The server tells the client that authentication is supported so that the client will actually try to authenticate. If the server doesn't say it supports auth, then everyone's a smurf and we act like we're connecting to a regular LAN server.
CLIENT → SERVER: authsupported
The client tells the server that it also supports authentication so that the client has time to actually authenticate. If the client doesn't say it supports authentication within some reasonably short interval (3 seconds?), the server either disconnects the client or allows it to connect unauthenticated as a smurf.
CLIENT → MASTER: getchallenge <clientPrivateToken>
The master server generates authentication tokens named <clientChallenge>, <clientChallengeResponse>, and <clientPublicToken>, saves them (with a 10-minute-or-so expiration), and sends them to the client.
CLIENT ← MASTER: challenge <clientChallenge> <clientChallengeResponse> <clientPublicToken>
Stage 2: The server proves it's authenticating against the same master.
The client provides an authentication challenge to the server which the server must answer correctly for authentication to continue. The server must pass this token back to the master in order to get the correct response.
CLIENT → SERVER: authchallenge <clientChallenge>
SERVER → MASTER: authchallenge <clientChallenge>
The master server looks up <clientChallenge> in its database and sends the matching <clientChallengeResponse> to the server. The challenge tuple is marked as used, and the master will not answer another request for the same challenge.
SERVER ← MASTER: authresponse <clientChallengeResponse>
The server passes the response back to the client to prove that the server actually contacted the master.
SERVER → CLIENT: authresponse <clientChallengeResponse>
The client checks the server's <clientChallengeResponse> against what it was expecting. If the responses match, we can move onwards. If the responses don't match, the server's probably up to no good disconnect, display a warning message, and possibly tell the master server to invalidate the challenge tuple.
Stage 3: The client is satisfied, send the final authentication token.
The server has proven to the client that it has (or has not) sent the challenge to the server, so the client can either disconnect or give the server the final authentication token.
CLIENT → SERVER: clientauth <clientPublicToken>
The server sends the <clientChallengeResponse> and <clientPublicToken> to the master server, which returns information about the client.
SERVER → MASTER: getinfo <clientChallengeResponse> <clientPublicToken>
SERVER ← MASTER: clientinfo <name> <tag> <appendTag> <guid> <numtribes> [tribeinfoN]
This satisfies the basic requirements: the server never sees the client's user/pass, and the client auth tokens aren't replayable (since they're associated with the challenge.) Unfortunately, it involves the master server a little more than I'd like (3 HTTP requests for each client connection) although not to the point where it'd be unreasonable to maintain. Unfortunately, it's vulnerable to the same MITM attack I described against your system.
Ergh. fabs() is the C library function to get the absolute value of a floating-point number, but it's not what I actually meant to say at all. (Sleep depreviation, bah!) I meant to say atof(), the function that converts a character string to a floating-point number, but I think tribes2 actually uses strtod(), and anyway that's still a terrible way of saying what I meant. I have no idea what my line of thought was last night...
Anyway, the point I was trying to make was that TorqueScript (in T2, at least) has a very strong tendency to convert numbers to strings, and when performing any math involving those numbers, they're converted back to a single-precision float. Since an IEEE single-precision float only has a 23-bit mantissa, numbers that don't fit in 23 bits may be rounded, and this loss of precision is completely unacceptable for any sort of cryptography. It looks like Wikipedia has a pretty good article on the internal structure of IEEE floats it's good information for any programmer to know, although it's not something you often need to worry about.
Doesn't look like an interlock protocol would help with that implementation either. There is a way to prevent such an attack using symmetric crypto and a mediation server, which I mentioned above, but it would be a bit of a logistical nightmare.
As far as external IP address connections... it isn't very much of an issue. Notice that I described that the client and server put the other party's IP address into the challenge. This can be accomplished through Torque Script (server side: cid.getAddress(), clientside: ServerConnection.getAddress()). It does, however, require the server (and client) to perform some interpretation as to whether the address the client (and server) put in is valid. If the client claims an RFC defined private network IP, the server will check to make sure the client is connecting from within the same RFC private network.
If the IP address originates over the Internet (as it would in almost all cases), a direct comparison between the server's actively routed IP address, and what the client claims should be sufficient. I already have a method for acquiring the actively routed IP address for a server or client. This could fail in extremely exotic multiple-uplink routing configurations (like people who strap two cable modems together), but if a client or server were behind one of these, I am sure that they would know how to configure it to avert difficulties. It will not fail under a typical NAT, even if there are NATs at both sides.
To that end, I'll provide another update with my system:
-All 3 of the 4096-bit RSA keys in use by various servers have been generated. I ran into a slight hiccup when entering the public potions of these keys into the DLL, but it is likely a late night typo that I can fix in a few minutes with a clear mind.
-Auto-update has been implemented. At the moment, this consists of a download/execution for a Ruby script. The download URLs must be signed by the update RSA-4096 key before a client will download or execute it. This will prevent anyone other than me from issuing updates to my system.
-Authentication server is done, except for server side storage and lookup. I decided to go for a light-weight in memory database, rather than a full blown SQL processing database. Considering how few queries need to be issues, this should meet the needs for at least 200,000 accounts. In the event we grow to that size, I'll convert to HSQL, Postgres, or MySQL.
-On the client side, Krash has practically finished with the GUIs. There is still some minor tweaking to do, and a few functions left to implement. I'm still working on the final DLL, so GUIs will still be a little while longer. Communication with the auth server is about 50% done, but this integrates tightly with UIs so relevant error messages can be provided. UI integration also needs to be done for the auto-update.
-I still need to finalize the inclusion of IP addresses into the nonce exchange during game server join, but the design is complete.
-Since we dumped OpenDHT due to its lacking reliability, Krash has implemented server listing based on the systems we used in prior master server outages.
Release on Friday? Maybe. Depends on how quickly we can get the remaining work completed.
You mentioned using an in-memory database versus the full blown MySQL -
It would seem at first glance that having that full-blown database would make community development easier later on - are you using a flat-file and then storing it in memory?
This way the player accounts from the server could link up to the in-game community browser.
Forum accounts tied into the master auth system etc.
A universal login.
Wondering your thoughts on how to link that up - figure I would pose it now as you are still in the thick of code.
This way the player accounts from the server could link up to the in-game community browser.
Forum accounts tied into the master auth system etc.
A universal login.
The interface to the database likely wouldn't change, just the manner in which the back-end stores and retrieves the information. That being said, we have actually given this subject a little bit of discussion.
The idea so far: The web server will be able to contact the authentication server to check if a name exists or to login to the name, but it will not automatically create a forum account when you register in the game (as you can imagine how paranoid some people can be). This means what will likely happen from the web end is that if you try to register with a name that exists on the game server, it will tell you it exists and ask you to log in. If you log in with the correct credentials, it will set up your forum account.
On the other hand, in-game services (when they're included) should not require any additional setup. Once you've registered and logged into the game, they should work fine. There could eventually be a web interface to these services (such as having "T-mails" connected to private messages, or viewing browser pages through the site), but that's still a while away.
So is the idea to actually fix the in game features for community and leave them completely apart of the game?
In an earlier post I had mentioned how some games now include basic web interfaces as a means of disseminating information. Such as the Matrix Online and their old "Sentinels."
Clicking a news stand in game loaded up a pseudo-browser that loaded a web page off a server.
There could be a few security risks with that idea however.
I'm a seasoned interactive developer for around 9 years. Full array of background web wise.
I'd be willing to lend a hand as I've mentioned, should the need arise.
I've finished the 1.0 version of the DLL distribution for the patch. All of the functionality (process isolated Ruby execution, hard coded RSA keys, LAN connection patch) is in, is tested, and should be working. I have sent the relevant files to Krash for testing on his machine (since I have a ton of development libraries installed on this computer which may be indirectly required by my DLLs).
Since fewer things are left than are done, I'll provide a list of things that still need to be completed.
-Auth server is sufficiently functional for development and testing purposes. I have not yet implemented the IP limiter on account signing requests, but other than that, most of the functionality has been tested and it works. There may be some minor bugs left, but those can only be tested for once the client GUIs and integration are complete.
-I still need to finish implementing the IP inclusive nonce fix as described earlier in this thread. The IP component of the nonce is sent in both directions, but neither the client nor server check the component for sanity. The sanity check design is figured out, it is just a matter of writing it in.
-I need to use the Ruby API to complete the client side account storage system. The account data needs to be stored within the GameData directory, rather than under base to prevent issues reading/writing to it when running multiple mods, and to prevent accidental modification or access via the TorqueScript file API.
-I need to write the TorqueScript network interface to the authentication server. The authentication server communication protocol has been designed and implemented on the authentication server side, so this isn't so much difficult as it is tedious.
After the above list is complete, Krash will have sufficient information to interface my backend scripts with the GUIs that he has created. Assuming my backend scripts are implemented correctly, the only things left after the GUIs are done are testing, packaging into an installer, and distribution.
We're getting close, but I don't want to commit to a release date yet, since I've set tentative dates repeatedly over the last few weeks that have come and gone. I'll keep posting updates to this thread as I finish the items on that list.
Comments
I'm with WarLovR on this one... my name is a lot less likely to get stolen, but still this is a valid concern. Someone malicious enough could reg a bunch of other people's names before they get the chance to.
I bet no one wants to be me anyway.
Either way, once the system is released, I'd bet people would be more worried about reserving their own name as opposed to someone else's. And with the 1 registration per week restriction, that pretty much guarantees you your own name. Unless somebody really, really wants it (more than their own).
Not that I am going to.
Edit: Unless you mark someone's T2 installation somehow after they register so they can't register again. That could be a good idea. As long as they don't figure out how it's marked and undo it.
Even if we were to deny a player their chosen account name simply because someone said that person wasn't who they said they were, not only would that be a breach of trust, but it would lead to dozens of other such requests with questionable intent.
What I can recommend to you is: Get the patch and create your account as soon as it's out. Most people, even those with malice in mind, will be making their own accounts and trying it out before they do anything else. Unless there's some bad apples, you're probably going to get the name you want just fine.
I'm not going to implement some sort of obscurity to prevent people from registering from the same machine, especially since I want people, who potentially have siblings, to register accounts for use.
The only secrets I plan to keep in this system are the private keys to authentication, updating, and community server delegation. I have kept my design transparent and open to encourage constructive criticism for and confidence in the system I create.
Vsf: I think we've all heard what you want to say. You want some sort of solution that doesn't alter the executable (ignoring the fact that accepting all inbound connections in LAN mode requires one), and you believe that you can effectively mitigate man-in-the-middle attacks without a cryptographically secured endpoint authentication.
I'll concede this: there is a way to do secure endpoint authentication in just TorqueScript with any symmetric cipher (I've personally implemented RC4 in TorqueScript, which is suitable), which would prevent man-in-the-middle attacks on player tokens. But, you are still talking about a cryptographic implementation. A system with this design is a logistical nightmare to manage, and a significant technical burden to your users. While such a design can be secure, asymmetric crypto certificates are a MUCH better route for half a dozen different reasons.
If you are still set on a script based solution, I'd be more than willing to tell you how to build such a system if you have not figured out what I'm talking about by this weekend. You can decide then if you feel that route is acceptable to you, over your pseudo-secure design. While I disagree with your choice, that doesn't mean I'll leave you to the wolves and trolls.
Lines like this concern me a little. Confidence is good. Overconfidence is weakness. Don't get me wrong, I've been rooting for you from the start and pointing other people to this project, but a split namespace is not good for Tribes 2. Whoever re-implements authentication first had better do it right and do it well.
Here is the attack I'm describing as far as I can tell, your design is vulnerable.
13) Eve really wants Game Server Bob to think she is Player Bob.
so...
When everything is said and done, Bob's server thinks it has been talking to Bob the entire time, and Bob's client is unaware that an attack has occurred. As I said, this is an active attack, and difficult to use to target a specific person; however, a griefer may only be interested in impersonating other players to avoid immediate detection and evade bans. For this purpose, connecting as effectively random (but distinct) players is sufficient connecting as someone with a good reputation is merely a bonus. The ability to connect as someone who you are not, even if you don't get to decide exactly who you connect as, seriously weakens the integrity of the entire system.
Unfortunately, I don't have a good solution to offer you (although admittedly, I haven't put much thought into for your design yet, having just seen it.) This problem is the very reason certification authorities exist, and that model doesn't translate terribly well.
I suspect asymmetric crypto is possible, but very probably not worth the effort.
I think that I've managed to design something that's as resistant to impersonation as your design (aside from the fact that the password is sent to the master server in the clear, a problem which can be remedied with enough time and patience to fight with TorqueScript), but it suffers from the same MITM problem as your design, and it's not NEARLY as elegant (out of necessity.) With real crypto, you have better tools available to address the problem.
Good luck!
***Sloik***, under some systems, yes, other systems no obviously a design thing. I do believe thought that in the end, some people will win, some will lose. It just depends on the system and the people running it. I could just as easily one day tell someone, "sorry, you have to make a new account... I can't tell who is who'. Others I may even ask other admins, if it's important enough, 'hey, can you help me validate this person?'. Either way I think the quick people will win, as you know, and, again, I hope for the kindness of people to kick in (cmon people, dont snicker too much at the funny guy on stage with the tu tu). In the other hand there are a few players I know that as a future system admin, I may reserve their names. I am glad you brought up that point, thank you.
***Thyth*** Yeah, you are right about the concern of altering compiled code. And call me naive (worse has been used) but you have made me think more into it all. For example, someone could say to a game server "I'm Vsf, from this IP with this GUID (which happens to bind my users and information together in SQL on the Auth Server), and that would be hacked if that GUID was found. But (for some, I know you see it Thyth) the idea would be a onetime use auth plan... server gens all auth info when you login via https browser and drops cookie, game client starts and reads it to dynamically create a LAN user as picked by the user (which was stored by server), client gives recent time, recent IP, static GUID and 60 minute use it or lose it temp GUID to game server, game server auths back to auth server, yeah or nae, player gets in or not, would be the idea. I suppose that is a word version of my diagram with some other details.
The way I am thinking, I could use crypto in M$ server side stuff (the auth server can do it C# has all the libs), but in reality the one key is a 64 digit random number only good for 60 minutes (until you pick the cookie up and its read into the game) or 10 or whatever. In this case its not even real crypto, just random (64 hexdec digits). Basically use the number on the top of the pad and throw away. Everyone gets a fresh spared square (I know some of you got that
The big problems (for me) are time, the T2 scripting (just not my forte but getting offers) that speak TCP pipe with Auth server (although non-secure httpObject may work with strings Thyth, did you say httpObject was bad or just the ssl version), tcp-pipe talking (again client), then later making it so a person does not need to quit and pick a new server to play on because at first the server list would be http page based, and clicking a link will give you the cookie with the server to connect to as well. Clearly going into better T2 script would be much nicer, but other than that, Id like to eliminate as much T2 internal GUI stuff as possible. The sign up, player creations, teams, player/team affiliations, (at first server lists) and maybe even finer player adjustments could be done on http pages. Hmmmm I do suppose that aligning a server side player storage to game side player profile would be needed, otherwise the storage implications may be trouble based on the server someone picks grrr . Well, I suppose you lose some weapons and gain others now anyway when going server to a new server somethimes
Okay sorry, I was kinda talking to myself toward the end not uncommon. Please forgive my rambling and especially if I stepped on what anyone said.
I guess I didn't think that through all of the way through when I decided that servers shouldn't need to register with the auth server. I'll implement the IP inclusive nonce fix into the scripts, with credit to you for spotting the bug.
Of course it's possible, but impractical. The arithmetic operations provide results that are not consistent with integer arithmetic above 23 bit numbers. I had a lot of fun when I decided to use ~%num instead of (%num * -1) - 1, to save a multiplication, and discovered that while ~0 appears to be -1, the numerical comparison (==) operation fails against a real -1. Someone could implement a safeAdd(), safeSubtract(), safeMultiply(), safeDivide() that uses the bitwise operations to perform arithmetic, but it would be terribly slow, and still limited to 32-bit numbers.
I attempted to go in a related direction several months ago, when I first came up with this project. I went the route of implementing arbitrary sized integers in arrays of 16-bit values. It was too slow to be usable for anything.
RC4 is one of the few "real" ciphers that can be implemented in the game script, since it uses a 256 byte mixer, with 8 bit values in each of them. Its implementation is also really short and simple. It just has known weaknesses that can be addressed by cutting off the first few thousand bytes.
I'd love to hear your design, and help you do a sanity check for issues like the one you noticed.
Edit: New encrypted blob is 192 bits.. not 160. Go basic arithmetic.
Rain, what are fabs()?
Oh, and Rain: depending on your design, you may be able to use an interlock protocol to prevent that type of man-in-the-middle attack. It isn't compatible with my design, but the concept may be compatible with yours.
You previously told me that you programmed in C#. I'm curious as to how you did not know what fabs() were. :P
It's kind of odd really... when you interview you can pick out the previous hard core C++'ers. Sometimes it even comes along with scorn. The question may be, would you prefer (as a business developer) to work in systems that well over 60% of the world developes in, or not, when it comes to your pay and what is predominenet in your local? For example, I'm quite sure silicone vally is far heavier Java than allot of Florida. My locale is HEAVY M$, light Java, but most business work is not in C++ any more.
I did just think of this though... if I'd seen the name "abs()", that would be a giveaway. But even then, what tossed me was the fact that (I am fairly sure) in the .NET lib, abs() works with all numerical types. So I was unsure if fabs() was like a blob or whatnot.
This sounds nice in theory, but NAT makes this a lot more complicated. Once again, Ruby will give you better tools to solve the problem (like access to the full BSD socket API), but there are some stumbling points. As far as I know, neither the server or the client can get its own IP address via TorqueScript, and behind NAT the OS may not even know its outside IP address (the one the server will see.) Similarly, on systems with more than one IP address (which is much more likely on the server side, of course) it can be difficult to determine which IP address the OS will use for the connection. Combining the two, if you have a dedicated server running on a PC behind NAT (with the appropriate ports forwarded on the router for the public to connect), the connection to your own server will be on the inside IP, and the server will need to figure that out for the challenge to work.
There are ways to allow the client to discover its own IP, of course, but that still won't solve the internal server problem or reliably cope with NAT with multiple external IPs. Since NAT with multiple external IPs is pretty uncommon (especially on a connection where hosting/playing a game would be sane), we could probably simply not support it, but any of these problems will be a pain to debug and a pain to explain to users expecting everything to Just Work.
Thanks!
Alright, let me try to make something presentable out of my notes... No perty pictures, sorry. :P All the time figures are tweakables, of course.
Stage 0: Client login
The client proves its identity to the master by providing a username and password. The only real purpose of <clientPrivateToken> is to avoid sending the username/password over the wire any more than is absolutely necessary.
CLIENT → MASTER: login <username> <password>
If the username and password are okay, the master generates a random authentication token, <clientPrivateToken>, which expires after 6 hours and is replaced by a new token on the next login. All authentication tokens are blocks of opaque, random data long enough to prevent brute-force attacks.
CLIENT ← MASTER: authtoken <clientPrivateToken>
Upon connection to a server...
Stage 1: Client provides its identity to the master.
SERVER → CLIENT: authsupported
The server tells the client that authentication is supported so that the client will actually try to authenticate. If the server doesn't say it supports auth, then everyone's a smurf and we act like we're connecting to a regular LAN server.
CLIENT → SERVER: authsupported
The client tells the server that it also supports authentication so that the client has time to actually authenticate. If the client doesn't say it supports authentication within some reasonably short interval (3 seconds?), the server either disconnects the client or allows it to connect unauthenticated as a smurf.
CLIENT → MASTER: getchallenge <clientPrivateToken>
The master server generates authentication tokens named <clientChallenge>, <clientChallengeResponse>, and <clientPublicToken>, saves them (with a 10-minute-or-so expiration), and sends them to the client.
CLIENT ← MASTER: challenge <clientChallenge> <clientChallengeResponse> <clientPublicToken>
Stage 2: The server proves it's authenticating against the same master.
The client provides an authentication challenge to the server which the server must answer correctly for authentication to continue. The server must pass this token back to the master in order to get the correct response.
CLIENT → SERVER: authchallenge <clientChallenge>
SERVER → MASTER: authchallenge <clientChallenge>
The master server looks up <clientChallenge> in its database and sends the matching <clientChallengeResponse> to the server. The challenge tuple is marked as used, and the master will not answer another request for the same challenge.
SERVER ← MASTER: authresponse <clientChallengeResponse>
The server passes the response back to the client to prove that the server actually contacted the master.
SERVER → CLIENT: authresponse <clientChallengeResponse>
The client checks the server's <clientChallengeResponse> against what it was expecting. If the responses match, we can move onwards. If the responses don't match, the server's probably up to no good disconnect, display a warning message, and possibly tell the master server to invalidate the challenge tuple.
Stage 3: The client is satisfied, send the final authentication token.
The server has proven to the client that it has (or has not) sent the challenge to the server, so the client can either disconnect or give the server the final authentication token.
CLIENT → SERVER: clientauth <clientPublicToken>
The server sends the <clientChallengeResponse> and <clientPublicToken> to the master server, which returns information about the client.
SERVER → MASTER: getinfo <clientChallengeResponse> <clientPublicToken>
SERVER ← MASTER: clientinfo <name> <tag> <appendTag> <guid> <numtribes> [tribeinfoN]
This satisfies the basic requirements: the server never sees the client's user/pass, and the client auth tokens aren't replayable (since they're associated with the challenge.) Unfortunately, it involves the master server a little more than I'd like (3 HTTP requests for each client connection) although not to the point where it'd be unreasonable to maintain. Unfortunately, it's vulnerable to the same MITM attack I described against your system.
Ergh. fabs() is the C library function to get the absolute value of a floating-point number, but it's not what I actually meant to say at all. (Sleep depreviation, bah!) I meant to say atof(), the function that converts a character string to a floating-point number, but I think tribes2 actually uses strtod(), and anyway that's still a terrible way of saying what I meant. I have no idea what my line of thought was last night...
Anyway, the point I was trying to make was that TorqueScript (in T2, at least) has a very strong tendency to convert numbers to strings, and when performing any math involving those numbers, they're converted back to a single-precision float. Since an IEEE single-precision float only has a 23-bit mantissa, numbers that don't fit in 23 bits may be rounded, and this loss of precision is completely unacceptable for any sort of cryptography. It looks like Wikipedia has a pretty good article on the internal structure of IEEE floats it's good information for any programmer to know, although it's not something you often need to worry about.
As far as external IP address connections... it isn't very much of an issue. Notice that I described that the client and server put the other party's IP address into the challenge. This can be accomplished through Torque Script (server side: cid.getAddress(), clientside: ServerConnection.getAddress()). It does, however, require the server (and client) to perform some interpretation as to whether the address the client (and server) put in is valid. If the client claims an RFC defined private network IP, the server will check to make sure the client is connecting from within the same RFC private network.
If the IP address originates over the Internet (as it would in almost all cases), a direct comparison between the server's actively routed IP address, and what the client claims should be sufficient. I already have a method for acquiring the actively routed IP address for a server or client. This could fail in extremely exotic multiple-uplink routing configurations (like people who strap two cable modems together), but if a client or server were behind one of these, I am sure that they would know how to configure it to avert difficulties. It will not fail under a typical NAT, even if there are NATs at both sides.
To that end, I'll provide another update with my system:
-All 3 of the 4096-bit RSA keys in use by various servers have been generated. I ran into a slight hiccup when entering the public potions of these keys into the DLL, but it is likely a late night typo that I can fix in a few minutes with a clear mind.
-Auto-update has been implemented. At the moment, this consists of a download/execution for a Ruby script. The download URLs must be signed by the update RSA-4096 key before a client will download or execute it. This will prevent anyone other than me from issuing updates to my system.
-Authentication server is done, except for server side storage and lookup. I decided to go for a light-weight in memory database, rather than a full blown SQL processing database. Considering how few queries need to be issues, this should meet the needs for at least 200,000 accounts. In the event we grow to that size, I'll convert to HSQL, Postgres, or MySQL.
-On the client side, Krash has practically finished with the GUIs. There is still some minor tweaking to do, and a few functions left to implement. I'm still working on the final DLL, so GUIs will still be a little while longer. Communication with the auth server is about 50% done, but this integrates tightly with UIs so relevant error messages can be provided. UI integration also needs to be done for the auto-update.
-I still need to finalize the inclusion of IP addresses into the nonce exchange during game server join, but the design is complete.
-Since we dumped OpenDHT due to its lacking reliability, Krash has implemented server listing based on the systems we used in prior master server outages.
Release on Friday? Maybe. Depends on how quickly we can get the remaining work completed.
You mentioned using an in-memory database versus the full blown MySQL -
It would seem at first glance that having that full-blown database would make community development easier later on - are you using a flat-file and then storing it in memory?
This way the player accounts from the server could link up to the in-game community browser.
Forum accounts tied into the master auth system etc.
A universal login.
Wondering your thoughts on how to link that up - figure I would pose it now as you are still in the thick of code.
Thanks.
- 27X-A
Soon... real soon!
The interface to the database likely wouldn't change, just the manner in which the back-end stores and retrieves the information. That being said, we have actually given this subject a little bit of discussion.
The idea so far: The web server will be able to contact the authentication server to check if a name exists or to login to the name, but it will not automatically create a forum account when you register in the game (as you can imagine how paranoid some people can be). This means what will likely happen from the web end is that if you try to register with a name that exists on the game server, it will tell you it exists and ask you to log in. If you log in with the correct credentials, it will set up your forum account.
On the other hand, in-game services (when they're included) should not require any additional setup. Once you've registered and logged into the game, they should work fine. There could eventually be a web interface to these services (such as having "T-mails" connected to private messages, or viewing browser pages through the site), but that's still a while away.
So is the idea to actually fix the in game features for community and leave them completely apart of the game?
In an earlier post I had mentioned how some games now include basic web interfaces as a means of disseminating information. Such as the Matrix Online and their old "Sentinels."
Clicking a news stand in game loaded up a pseudo-browser that loaded a web page off a server.
There could be a few security risks with that idea however.
I'm a seasoned interactive developer for around 9 years. Full array of background web wise.
I'd be willing to lend a hand as I've mentioned, should the need arise.
Thanks for the reply Krash and hope you're well.
-27X-A
Since fewer things are left than are done, I'll provide a list of things that still need to be completed.
-Auth server is sufficiently functional for development and testing purposes. I have not yet implemented the IP limiter on account signing requests, but other than that, most of the functionality has been tested and it works. There may be some minor bugs left, but those can only be tested for once the client GUIs and integration are complete.
-I still need to finish implementing the IP inclusive nonce fix as described earlier in this thread. The IP component of the nonce is sent in both directions, but neither the client nor server check the component for sanity. The sanity check design is figured out, it is just a matter of writing it in.
-I need to use the Ruby API to complete the client side account storage system. The account data needs to be stored within the GameData directory, rather than under base to prevent issues reading/writing to it when running multiple mods, and to prevent accidental modification or access via the TorqueScript file API.
-I need to write the TorqueScript network interface to the authentication server. The authentication server communication protocol has been designed and implemented on the authentication server side, so this isn't so much difficult as it is tedious.
After the above list is complete, Krash will have sufficient information to interface my backend scripts with the GUIs that he has created. Assuming my backend scripts are implemented correctly, the only things left after the GUIs are done are testing, packaging into an installer, and distribution.
We're getting close, but I don't want to commit to a release date yet, since I've set tentative dates repeatedly over the last few weeks that have come and gone. I'll keep posting updates to this thread as I finish the items on that list.