Multiple players in the same household...
I just downloaded Tribes Next, after a 7 year Tribes break I'm back and ready to have fun! My little brother has heard a lot about this game that was before his time - but when we try to register his account it gives an error.
Looking up the error I found:
"The Authentication Server understood your request, but chose not to fulfill it
This is the message returned by the auth server when an account has already been registered in the past seven days or the maxium of five have been registered with your IP address." (ps there's a typo in maximum)
I was wondering if I had him take the laptop to another network, registered his account, then brought it back over to the house would it let us connect to the auth server even though we have the same IP?
Looking up the error I found:
"The Authentication Server understood your request, but chose not to fulfill it
This is the message returned by the auth server when an account has already been registered in the past seven days or the maxium of five have been registered with your IP address." (ps there's a typo in maximum)
I was wondering if I had him take the laptop to another network, registered his account, then brought it back over to the house would it let us connect to the auth server even though we have the same IP?
Comments
That should do it. You can only create one account per week at the same ip up to a maximum of 5 accounts. But if you create his account from somewhere else with a different ip you'll both be able to play from home.
Use account bans for problem individuals. I assume the goal is to have the auth server act as a global ban mechanism for truly disruptive people. Assuming that the problem individuals are creating new accts to cause trouble, you could use a locally stored hash/key/whatever, that identifies the INSTALLATION, not the user themselves. This will force users logging in from a given machine to reinstall, or hit you guys up. One could jump to another machine, but that eventually runs dry also. At this point you could end up with a plea from someone running an internet cafe' etc., for forgiveness of customer actions. To avert that issue, you could have a multi-user recognition file, where you could be told by people allowing public access that they made need special treatment, assuming they cooperate in reducing idiots.
At the end of the day, no security is going to protect from the malicious user, with bad intentions. Using an install side encrypted key for identification makes the typical loser move on or straighten up. Their IP can change, but the install, until reinstalled, won't.
I personally wouldn't bother at all, but I understand that security is an issue we all face.
As far as tagging individual installations... this was discussed, and there is no good way to do it. Obviously, each of the installations will be essentially identical once the game is installed from the GSI and then patched. I doubt people would be comfortable having the patch analyze other contents of system files, registry, or hardware identification. Finally, any such system that did this would rely on secure attestation of system state by a client that may not be trusted. It's too much security through obscurity.
IP addresses are a scarce resource, and they can be enforced on the server side. Do some people have the ability to change their IP addresses to a huge subset? Sure, but everyone has the ability to delete/modify/spoof a tag placed in the installation, especially since the entire client/game-server portion of the authentication system is open source.
I know the system, as is, is imperfect. Prior to launch, I brought up the possibility of doing a referral system where you would need vetting from an existing account holder to activate the account. This would create a hierarchy of referrals which could be used to prune entire portions of self-referring malicious users. There were groups of users who strongly approved and groups of users who strongly disapproved of such a system. I chose IP rate limitation as a reasonable, objective account limiter.