Authentication server is done now. I've implemented the IP limiter and persistent database for last account generation for an IP address. I also did a full test of all of the functionality, so the authentication server itself is ready for launch.
The policy for account limitations is as follows. First, each IP address has the ability to generate one account per week, up to a maximum of 5 accounts for the lifetime. In the event a person requires more than 5 accounts, case-by-case exceptions will be granted when deemed necessary. Second, there is a limited profanity filter to keep some offensive words from being generated as part of accounts. Thirdly, any account that has uppercase i's will be checked against accounts containing lowercase L's, and vice versa; I've seen name abuse that exploited this, since the font used by the game does not provide a visual distinction between those glyphs.
So... to do list:
-I haven't done the IP nonce sanity check yet. That's still on the list. This will take an hour.
-I haven't implemented the client side credential store in Ruby yet. That's still on the list. This will take an hour.
-I haven't finished the network connector to the authentication server in Torque Script. Now that the auth server code is finished, and all error codes have been set, I can proceed with this script. This will take a few hours.
Given how busy things are for me, don't hold your breath for a release. If I had copious free time, I could finish the components on the list in an afternoon, but as it is, I can only fit bits and pieces in between more important commitments.
Authentication server is done now. I've implemented the IP limiter and persistent database for last account generation for an IP address. I also did a full test of all of the functionality, so the authentication server itself is ready for launch.
The policy for account limitations is as follows. First, each IP address has the ability to generate one account per week, up to a maximum of 5 accounts for the lifetime. In the event a person requires more than 5 accounts, case-by-case exceptions will be granted when deemed necessary. Second, there is a limited profanity filter to keep some offensive words from being generated as part of accounts. Thirdly, any account that has uppercase i's will be checked against accounts containing lowercase L's, and vice versa; I've seen name abuse that exploited this, since the font used by the game does not provide a visual distinction between those glyphs.
So... to do list:
-I haven't done the IP nonce sanity check yet. That's still on the list. This will take an hour.
-I haven't implemented the client side credential store in Ruby yet. That's still on the list. This will take an hour.
-I haven't finished the network connector to the authentication server in Torque Script. Now that the auth server code is finished, and all error codes have been set, I can proceed with this script. This will take a few hours.
Given how busy things are for me, don't hold your breath for a release. If I had copious free time, I could finish the components on the list in an afternoon, but as it is, I can only fit bits and pieces in between more important commitments.
I've implemented the IP inclusive nonce anti-MTiM fix for the attack described by Rain. The script will recognize LAN connections for the following ranges: 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.32.255.255, 192.168.0.0 to 192.168.255.255, and 169.254.0.0 to 169.254.255.255. These are the RFC defined private IP ranges (and the last one is the Zeroconf IP range). Servers and clients will infer potential valid LAN IP addresses from these ranges for connections that don't come from the Internet. In the event a server or client discovers an inconsistency with the IP addresses sent over the link, they will terminate the connection prior to the transmission of the decrypted server token. This will prevent Rain's attack.
So... to do list:
-Client side credential store in Ruby.
-Authentication server network connector in Torque Script.
So in laymans terms, if we run through a router of some sort we'll still be able to connect without the system thinking we're bogus? My router (linksys,) issues 192.168.x.x IP's. Some of the other ranges which you have described look like other brand issued router addresses.
No. The 192.168.x.x, 172.16.x.x, an 10.x.x.x IP network ranges:
Class Start End Notes
A 10.0.0.0 10.255.255.255 -
B 172.16.0.0 172.31.255.255 -
C 192.168.0.0 192.168.255.255 -
... Are PRIVATE IP address ranges and are NOT route-able over the Internet backbone.
Those addresses are only valid INSIDE your home network.
When you access the Internet from any of your inside computers, all of those IP addresses are PAT-ed, Port Address Translated to the most recent PUBLIC IP address assigned to the outside interface of your Linksys router.
"showmyip com" will show you the current IP address your DSL/Cable network is using for outbound connections.
If you are not using a router and connect directly to your DSL/Cable modem, the ethernet interface of your computer MAY have the public IP address assigned directly to it.
I should describe the reason for including a LAN check. As part of the initial plan of using OpenDHT, I wrote a script that would query an online service for the currently active Internet routable address in use by the game.
When Rain described a viable man-in-the-middle attack, I considered two possible solutions. The first solution would be to issue time limited certificates tied to Internet routable addresses used by the server, and use a bidirectional RSA method for identification; a major disadvantage with this approach is the continual reliance on the authentication server for server authentication, and an increase in the CPU utilization required for the client-server handshake. The second solution would be to include reciprocal IP addresses as part of the nonce's used in the handshake. I went with the latter.
This is really straightforward if you connect over the Internet. The server uses the script mentioned above to determine its Internet routable address. The client says who it is connecting to, and the server can check if the two addresses are equal. Unfortunately, due to the ever more desperate shortage of IP(v4) addresses, abominations like Network Address Translation are used on internal networks. If a client is on a LAN, the address they use to connect to the server will be one of the RFC defined private network ranges, and not the Internet routable one determined by the server. The script I wrote for determining if the address is acceptable will check the alleged incoming address for IP addresses within the same private IP range if a private IP range is used.
This is purely to prevent breaking LAN play, while preventing the smart MiTM attack.
If you run a LAN on any other IP address range than the ones described with non-Internet routable IP addresses (i.e. IANA reserved 1.*.*.*, 2.*.*.*, 5.*.*.* or any of the other invalid ranges), then LAN play will fail. Considering most of the routers purchased by mere mortals use the 192.168.*.* range, and actually comply with IANA allocations and reservations, this won't be an issue.
Here is a suggestion for down the line when you start using the auto-updater to add more features: How about a map auto-downloader? ByTor already made one that tries to download the map from Tribes2Maps.com if it's there, but it would be better to have it download the maps (or just the .ter and .dts files) straight from the server. This would hopefully eliminate the drawback of making/running client-side maps. I can think of a few security holes that would need to be plugged, but no need to discuss them now. This is just a suggestion for the future.
In the meantime, something you can quickly toss in with the initial release of the patch is a couple popular client-side map packs. There's no need for the patch to only update functionality, especially when it should be pretty easy to have it update content as well in the form of some map packs. Let me know if this is something you'd be open to, and I can start putting together a single map pack vl2 of some of the more popular map packs (TWL, TWL2, x2, OSL, Cluster, Euro2, any more that anyone can think of). It would increase the download size by a couple hundred MB, which might be a concern, but it would make things much more convenient for people who want to try playing on any server that might pop up in the future and run those maps. At the very least, Rebels can start running Katabatic(x2) or TWL-Katabatic instead of the dead-stop-filled regular Katabatic.
I like those ideas, but if people don't want to download the extra maps, maybe just heavily advertise the map packs wherever the patch is hosted. Everyone will see the map packs there and probably want to download them.
Here is a suggestion for down the line when you start using the auto-updater to add more features: How about a map auto-downloader? ByTor already made one that tries to download the map from Tribes2Maps.com if it's there, but it would be better to have it download the maps (or just the .ter and .dts files) straight from the server. This would hopefully eliminate the drawback of making/running client-side maps. I can think of a few security holes that would need to be plugged, but no need to discuss them now. This is just a suggestion for the future.
In the meantime, something you can quickly toss in with the initial release of the patch is a couple popular client-side map packs. There's no need for the patch to only update functionality, especially when it should be pretty easy to have it update content as well in the form of some map packs. Let me know if this is something you'd be open to, and I can start putting together a single map pack vl2 of some of the more popular map packs (TWL, TWL2, x2, OSL, Cluster, Euro2, any more that anyone can think of). It would increase the download size by a couple hundred MB, which might be a concern, but it would make things much more convenient for people who want to try playing on any server that might pop up in the future and run those maps. At the very least, Rebels can start running Katabatic(x2) or TWL-Katabatic instead of the dead-stop-filled regular Katabatic.
i think thats a good idea, but a side note.... ive around 3 gigs in my dynamix folder alone in skins and maps, and ive a hugely bad feeling ive not even got them all yet, and that ive only scratched the surface... so while its a good idea, it would take about 2 - 15 hours (depending on download speed and file's host location) and those eager to play might get fustrated at that... =/
Well Euro2 is when America stopped borrowing maps from the Euro map packs. I think every Euro2 and x2 map is a part of one of the TWL maps packs anyway, so I probably shouldn't have mentioned them anyway.
Thanks to all those working so tirelessly for the greater good (greater good = Tribes 2).
If a clientside patch can't be avoided, I see no downside to including the most popular map packs.
But I foresee very serious problems for individual server hosts who try to match troublemakers' IPs and GUIDs after GUIDs have been issued.
For example, Comcast clients can pull IPs from a vast array of numbers with little visible correlation. Any back-end process of correlating IPs and GUIDs from an examination of server logs would be extremely problematic, especially if you're dealing with dedicated griefers who are able to change their Comcast dynamic IPs continually, and who will use that capability to collect a large number of GUIDs.
Why not do the screening front-end, or let individual server hosts set up their own separate authentication servers and do their own screening according to their own criteria? This would result in replication of warriors and GUIDs from one server to another, but that's not necessarily a drawback; many players already use different accounts for different mods. Server hosts can still exchange information on troublemakers and post links to other servers on their own websites in order to prevent community fragmentation.
In my opinion, most of the problems on our pub servers are caused by a small number of hardcore troublemakers, and our inability to effectively deal with their disruptions of gameplay. As I see it, blocking their acquisition of GUIDs would be a huge benefit to the T2 community.
it has been stated numerous time that the game should work as before, so while id say that you could ban by guid im gonna have to wait and confirm what i just told you...
In my opinion, most of the problems on our pub servers are caused by a small number of hardcore troublemakers, and our inability to effectively deal with their disruptions of gameplay. As I see it, blocking their acquisition of GUIDs would be a huge benefit to the T2 community.
Additionally, we not only want to save T2, but also attract new players. You're going to be hard pressed to attract and keep anyone around if you've got these guys running rampant on servers. Things are starting to get out of hand even now, and the master server has only been down a couple weeks.
Unfortunately GUID bans don't help against a griefer with twenty (or however many) GUIDs. Even worse if said griefer can always go back and get more from the GUID well.
With the maps, another good solution could be just adding map packs in with the auto-updater later, but make them an optional download. Like, if someone hasn't downloaded them yet it says "You have not yet downloaded all of the map packs available, do you wish to do that now?". Etc.
But the individual map auto-downloader that gets the files from the game server is definitely the best idea, as it will also take care of maps that aren't a part of map packs.
There is nothing stopping any server administrator from producing their own script to control access however they see fit. However, I don't think it is my responsibility add an extra layer of burden to clients, and I don't think any system that forces users to jump through extra hoops would survive.
You outline a rather serious problem with the two current player identification methods. GUIDs aren't reliable because people will be able to acquire more than one. IPs aren't reliable because people will be able to change theirs. If you consider a core group of dedicated assholes who are adept enough to generate accounts and change IPs continually, then any client side modifications to the executable that harvests unique hardware identification would also be bound to fail, and any system that you generate to constrict use of your own servers would be equally moribund.
I'm willing to discuss an alternative method for identifying individual humans, regardless of even the computer they are using, and that can be implemented completely on the server side. It's a set of experimental ideas, but if properly implemented, could solve your problem rather well. Identification wouldn't be instantaneous (maybe a few minutes of the person playing), but it would be completely automatic, and extremely difficult to spoof.
With regards to the patch itself... updates:
I implemented the credential and key stores in Ruby on the client side. These are used to store the account data in a protected manner, outside of the TorqueScript accessible file sandboxes. The code actually ended up extremely short (12 lines) due to Ruby's extremely concise file reading and writing API.
The only major thing left for me to do is to write the network interface to the authentication server, then do a final round of debugging before Krash connects the UIs. After Krash hooks up the UIs, we'll write an automated patcher/installer, and release it.
I don't think it is my responsibility add an extra layer of burden to clients, and I don't think any system that forces users to jump through extra hoops would survive.
Absolutely. But would you consider helping individual server hosts set up their own authentication/list servers if they wish, so they could implement their own extra hoops for issuing GUIDs?
I'm willing to discuss an alternative method for identifying individual humans, regardless of even the computer they are using, and that can be implemented completely on the server side. It's a set of experimental ideas, but if properly implemented, could solve your problem rather well. Identification wouldn't be instantaneous (maybe a few minutes of the person playing), but it would be completely automatic, and extremely difficult to spoof.
Obviously I don't know what's involved in your alternative method for identifying individual humans. We're grateful for any and all anti-asshat measures, but as far as I can tell, based on the information I now have, the only effective strategy to keep our pubs alive is to block, or at least reduce, the issuance of GUIDs to unauthorized, repeat applicants or known troublemakers. As long as players can easily acquire unlimited numbers of GUIDs, we have little or no control over our own servers.
Comments
Another ten years.
The policy for account limitations is as follows. First, each IP address has the ability to generate one account per week, up to a maximum of 5 accounts for the lifetime. In the event a person requires more than 5 accounts, case-by-case exceptions will be granted when deemed necessary. Second, there is a limited profanity filter to keep some offensive words from being generated as part of accounts. Thirdly, any account that has uppercase i's will be checked against accounts containing lowercase L's, and vice versa; I've seen name abuse that exploited this, since the font used by the game does not provide a visual distinction between those glyphs.
So... to do list:
-I haven't done the IP nonce sanity check yet. That's still on the list. This will take an hour.
-I haven't implemented the client side credential store in Ruby yet. That's still on the list. This will take an hour.
-I haven't finished the network connector to the authentication server in Torque Script. Now that the auth server code is finished, and all error codes have been set, I can proceed with this script. This will take a few hours.
Given how busy things are for me, don't hold your breath for a release. If I had copious free time, I could finish the components on the list in an afternoon, but as it is, I can only fit bits and pieces in between more important commitments.
Sounds like good news. :]
Every1 in australia will thank you
as do I
Hamma
So... to do list:
-Client side credential store in Ruby.
-Authentication server network connector in Torque Script.
Class Start End Notes
A 10.0.0.0 10.255.255.255 -
B 172.16.0.0 172.31.255.255 -
C 192.168.0.0 192.168.255.255 -
... Are PRIVATE IP address ranges and are NOT route-able over the Internet backbone.
Those addresses are only valid INSIDE your home network.
When you access the Internet from any of your inside computers, all of those IP addresses are PAT-ed, Port Address Translated to the most recent PUBLIC IP address assigned to the outside interface of your Linksys router.
"showmyip com" will show you the current IP address your DSL/Cable network is using for outbound connections.
If you are not using a router and connect directly to your DSL/Cable modem, the ethernet interface of your computer MAY have the public IP address assigned directly to it.
When Rain described a viable man-in-the-middle attack, I considered two possible solutions. The first solution would be to issue time limited certificates tied to Internet routable addresses used by the server, and use a bidirectional RSA method for identification; a major disadvantage with this approach is the continual reliance on the authentication server for server authentication, and an increase in the CPU utilization required for the client-server handshake. The second solution would be to include reciprocal IP addresses as part of the nonce's used in the handshake. I went with the latter.
This is really straightforward if you connect over the Internet. The server uses the script mentioned above to determine its Internet routable address. The client says who it is connecting to, and the server can check if the two addresses are equal. Unfortunately, due to the ever more desperate shortage of IP(v4) addresses, abominations like Network Address Translation are used on internal networks. If a client is on a LAN, the address they use to connect to the server will be one of the RFC defined private network ranges, and not the Internet routable one determined by the server. The script I wrote for determining if the address is acceptable will check the alleged incoming address for IP addresses within the same private IP range if a private IP range is used.
This is purely to prevent breaking LAN play, while preventing the smart MiTM attack.
If you run a LAN on any other IP address range than the ones described with non-Internet routable IP addresses (i.e. IANA reserved 1.*.*.*, 2.*.*.*, 5.*.*.* or any of the other invalid ranges), then LAN play will fail. Considering most of the routers purchased by mere mortals use the 192.168.*.* range, and actually comply with IANA allocations and reservations, this won't be an issue.
In the meantime, something you can quickly toss in with the initial release of the patch is a couple popular client-side map packs. There's no need for the patch to only update functionality, especially when it should be pretty easy to have it update content as well in the form of some map packs. Let me know if this is something you'd be open to, and I can start putting together a single map pack vl2 of some of the more popular map packs (TWL, TWL2, x2, OSL, Cluster, Euro2, any more that anyone can think of). It would increase the download size by a couple hundred MB, which might be a concern, but it would make things much more convenient for people who want to try playing on any server that might pop up in the future and run those maps. At the very least, Rebels can start running Katabatic(x2) or TWL-Katabatic instead of the dead-stop-filled regular Katabatic.
i think thats a good idea, but a side note.... ive around 3 gigs in my dynamix folder alone in skins and maps, and ive a hugely bad feeling ive not even got them all yet, and that ive only scratched the surface... so while its a good idea, it would take about 2 - 15 hours (depending on download speed and file's host location) and those eager to play might get fustrated at that... =/
The 6 packs that I named total 233 Mb.
If a clientside patch can't be avoided, I see no downside to including the most popular map packs.
But I foresee very serious problems for individual server hosts who try to match troublemakers' IPs and GUIDs after GUIDs have been issued.
For example, Comcast clients can pull IPs from a vast array of numbers with little visible correlation. Any back-end process of correlating IPs and GUIDs from an examination of server logs would be extremely problematic, especially if you're dealing with dedicated griefers who are able to change their Comcast dynamic IPs continually, and who will use that capability to collect a large number of GUIDs.
Why not do the screening front-end, or let individual server hosts set up their own separate authentication servers and do their own screening according to their own criteria? This would result in replication of warriors and GUIDs from one server to another, but that's not necessarily a drawback; many players already use different accounts for different mods. Server hosts can still exchange information on troublemakers and post links to other servers on their own websites in order to prevent community fragmentation.
In my opinion, most of the problems on our pub servers are caused by a small number of hardcore troublemakers, and our inability to effectively deal with their disruptions of gameplay. As I see it, blocking their acquisition of GUIDs would be a huge benefit to the T2 community.
Additionally, we not only want to save T2, but also attract new players. You're going to be hard pressed to attract and keep anyone around if you've got these guys running rampant on servers. Things are starting to get out of hand even now, and the master server has only been down a couple weeks.
But the individual map auto-downloader that gets the files from the game server is definitely the best idea, as it will also take care of maps that aren't a part of map packs.
You outline a rather serious problem with the two current player identification methods. GUIDs aren't reliable because people will be able to acquire more than one. IPs aren't reliable because people will be able to change theirs. If you consider a core group of dedicated assholes who are adept enough to generate accounts and change IPs continually, then any client side modifications to the executable that harvests unique hardware identification would also be bound to fail, and any system that you generate to constrict use of your own servers would be equally moribund.
I'm willing to discuss an alternative method for identifying individual humans, regardless of even the computer they are using, and that can be implemented completely on the server side. It's a set of experimental ideas, but if properly implemented, could solve your problem rather well. Identification wouldn't be instantaneous (maybe a few minutes of the person playing), but it would be completely automatic, and extremely difficult to spoof.
With regards to the patch itself... updates:
I implemented the credential and key stores in Ruby on the client side. These are used to store the account data in a protected manner, outside of the TorqueScript accessible file sandboxes. The code actually ended up extremely short (12 lines) due to Ruby's extremely concise file reading and writing API.
The only major thing left for me to do is to write the network interface to the authentication server, then do a final round of debugging before Krash connects the UIs. After Krash hooks up the UIs, we'll write an automated patcher/installer, and release it.
Absolutely. But would you consider helping individual server hosts set up their own authentication/list servers if they wish, so they could implement their own extra hoops for issuing GUIDs?
Obviously I don't know what's involved in your alternative method for identifying individual humans. We're grateful for any and all anti-asshat measures, but as far as I can tell, based on the information I now have, the only effective strategy to keep our pubs alive is to block, or at least reduce, the issuance of GUIDs to unauthorized, repeat applicants or known troublemakers. As long as players can easily acquire unlimited numbers of GUIDs, we have little or no control over our own servers.