Master Policy Reforms

Old stuff gets archived here.
TIHan
Retired Staff / Community Team Member
Posts: 34
Joined: Thu May 31, 2012 11:30 pm
Location: Tennessee

RE: Master Policy Reforms

#21

Post by TIHan » Sun Jun 03, 2012 3:47 am

Metal wrote: Terribly. It's not working to hot now. We ban 1 person by IP, let's say full ip, within an hour they can change it and come back. And the cycle continues. We ban dynamic IP's, we ban a lot of people but it gets rid of the person who was troublesome to begin with, but we can whitelist IP's. It's lose-lose either way. I'd suggest an account system. imo, that might make things easier.
Troubling players will always find away around the system no matter what we do. An account system would be just be harder on us, as they can just create new accounts easily.

Tribeam
 
Posts: 25
Joined: Thu May 24, 2012 10:21 pm

RE: Master Policy Reforms

#22

Post by Tribeam » Sun Jun 03, 2012 4:04 am

Anything is better than IP banning, and the account system has its benefits if done right

DC3 was a good example, I'm not gonna say the methods it used to ban but they were very very effective.

But then the problem is, open source, I talked to torr about this like a week or 2 ago and he said something as to why it wouldn't fully work to how I was explaining but I don't remember much of that convo...

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Master Policy Reforms

#23

Post by Torr Samaho » Sun Jun 03, 2012 9:31 am

The login server proposal has some ideas on how an account system can work in an open source environment and how it can be used to ban people.

TIHan
Retired Staff / Community Team Member
Posts: 34
Joined: Thu May 31, 2012 11:30 pm
Location: Tennessee

RE: Master Policy Reforms

#24

Post by TIHan » Sun Jun 03, 2012 6:55 pm

I think an account system wouldn't help our situation. An IP + an account ban can still be circumvented; players can change their IP and create new accounts. Building such a system would be a waste of time and we would need people to maintain it with addition to the drama that accounts can cause.

Simply put, you will never be able to stop cheaters and troubling players, only slow them down. But attempting tactics against these players that affect the maintainability and development of this project is the worst thing you can do, e.g. being closed source before. The cheaters are winning in that case.

Server admins should ultimately be responsible for how their servers are played. We should have no involvement other than providing a list of servers, period. This makes it easy for us to maintain this project, as we simply do not have to moderate every single thing that occurs.
Last edited by TIHan on Sun Jun 03, 2012 8:16 pm, edited 1 time in total.

Tenchu
Retired Staff / Community Team Member
Posts: 331
Joined: Mon Jun 04, 2012 2:29 am
Location: Nocru illa dan
Clan: Lost Faction
Clan Tag: LF

RE: Master Policy Reforms

#25

Post by Tenchu » Mon Jun 04, 2012 7:55 am

Konar6 wrote:But they can host their own servers too (which is what one known hacker, Tenchu, is about to do).
I have no doubt you're the ignorant type who's content with seeing me as nothing but a cheater, considering you've been in the community for what, 2 years? I've been playing Skulltag since you were most likely still in grade school. You literally do not know me. Regardless, how you choose to view me as a player is your own business but I'd appreciate it if you left me out of public matters, I have nothing to do with them anymore. Thanks.

That being said, if I had any plans to host servers, I would have already done so long ago on Skulltag.
Last edited by Tenchu on Thu Jun 07, 2012 1:15 am, edited 1 time in total.

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Master Policy Reforms

#26

Post by Torr Samaho » Mon Jun 04, 2012 7:29 pm

TIHan wrote: I think an account system wouldn't help our situation. An IP + an account ban can still be circumvented; players can change their IP and create new accounts. Building such a system would be a waste of time and we would need people to maintain it with addition to the drama that accounts can cause.
Did you read through the whole tracker discussion and say that the specific ideas we had won't help or are you just commenting on how you think account systems work in general?
TIHan wrote: Server admins should ultimately be responsible for how their servers are played. We should have no involvement other than providing a list of servers, period.
Moderating servers and providing ways to let server admins keep out people they don't want in their servers are two very different things. It may be arguable to which extend our staff should be involved with the former but IMHO there is no question that we, the devs, should provide the latter. Look at it like this: You say that server admins should be responsible for how their servers are played. I think it's safe to say that they don't want cheaters in their servers. How are they supposed to keep them out? IP bans apparently don't work.

TIHan
Retired Staff / Community Team Member
Posts: 34
Joined: Thu May 31, 2012 11:30 pm
Location: Tennessee

RE: Master Policy Reforms

#27

Post by TIHan » Tue Jun 05, 2012 3:30 am

Torr Samaho wrote: Did you read through the whole tracker discussion and say that the specific ideas we had won't help or are you just commenting on how you think account systems work in general?
I did not read the entire discussion all the way through (It is indeed very lengthy), but I did the read most of what was proposed. This will slow cheaters down, but it of course will not rid of them. There will always be a workaround. So my question with what was proposed, how will it fair against thousands of players?
Torr Samaho wrote:How are they supposed to keep them out? IP bans apparently don't work.
You will never be able to keep them out. If we get a huge number of players playing this game, we are absolutely going to have a ton of cheaters. Perhaps the only thing we can do is slow them down... with the cost of the infrastructure, maintenance and inconvenience of new players. This is a free game, this means when they are banned they do not have to pay for the game again to come back.

The solution to cheaters is this: The gameplay itself is designed in such a way that aimbots or wallhacks do not determine that the player will have dramatically more success at winning. In our case, that solution is Survival Co-op/Invasion. How is an aimbot or wallhack going to help someone in invasion?

IMHO, the future of this port is going to be within what we do with Survival Co-op. Due to this port's uniqueness of how co-op works versus other more modern day games, new players will come due to this reason. But first, we need to make it as best as we can, and competitive. Thank you SNS.

Konda
Forum Regular
Posts: 487
Joined: Thu Jun 07, 2012 5:22 pm

RE: Master Policy Reforms

#28

Post by Konda » Sat Jun 09, 2012 7:24 pm

TIHan wrote:The solution to cheaters is this: The gameplay itself is designed in such a way that aimbots or wallhacks do not determine that the player will have dramatically more success at winning. In our case, that solution is Survival Co-op/Invasion. How is an aimbot or wallhack going to help someone in invasion?

IMHO, the future of this port is going to be within what we do with Survival Co-op. Due to this port's uniqueness of how co-op works versus other more modern day games, new players will come due to this reason. But first, we need to make it as best as we can, and competitive. Thank you SNS.
It is not guaranteed that players won't move from co-op to competitive mods. A lot of competitive mods that alter the gameplay drastically are being played today, and you don't get to see most of those mods' gameplay in modern games. Right now it's quite the opposite situation, actually. Most of the new people are coming to check out mods like AOW, GVH, Zombie Horde, and such, as words about those mods are being spread between friends IRL. And most of them stay. In the end they find the mod more fun than classic Zandronum game modes.

I also don't get how the whitelist system works for range banned players. If the banned player has a dynamic IP, they can just change it to an IP that's dramatically different (in the range) than the one they had at the time they were banned, and present themselves as some new guy who has no clue what's going on and why they're banned. Do you compare locations before whitelisting?
Last edited by Konda on Sat Jun 09, 2012 7:30 pm, edited 1 time in total.

Code: Select all

<Synert> fuck
<Synert> plugged in my memory stick and got a bsod

User avatar
Mr. Chris
 
Posts: 91
Joined: Wed Jun 06, 2012 6:45 pm
Location: Long Island, New York
Contact:

RE: Master Policy Reforms

#29

Post by Mr. Chris » Sat Jun 09, 2012 10:28 pm

Has anyone come up with the thought of banning by MAC address? It could stop most people but the most ambitious folk would either spoof the MAC or get a new network card.

Qent
Retired Staff / Community Team Member
Posts: 1424
Joined: Tue May 29, 2012 7:56 pm
Contact:

RE: Master Policy Reforms

#30

Post by Qent » Sat Jun 09, 2012 10:44 pm

In addition to IP, or instead? (I have no idea how feasible it is.)

Catastrophe
Retired Staff / Community Team Member
Posts: 2558
Joined: Sat Jun 02, 2012 2:44 am

RE: Master Policy Reforms

#31

Post by Catastrophe » Sun Jun 10, 2012 12:25 am

I can change my ip by changing my mac address, this is a terrible idea.
Last edited by Catastrophe on Sun Jun 10, 2012 12:25 am, edited 1 time in total.

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Master Policy Reforms

#32

Post by Torr Samaho » Sun Jun 10, 2012 12:57 pm

Mr. Chris wrote: Has anyone come up with the thought of banning by MAC address?
The servers can't deduce the client's MAC address from incoming traffic. And if you would make the clients explicitly send their MAC address to the server, you would have to trust the clients to be honest about this which you can't be either. In particular not now that the source is open.

VortexCortex
 
Posts: 27
Joined: Mon Jun 11, 2012 1:43 am
Location: Houston
Contact:

RE: Master Policy Reforms

#33

Post by VortexCortex » Mon Jun 11, 2012 10:21 pm

Essentially you want to identify endpoints as being one of two (or more) classes. Thus you have two approaches: Black List or White List. They both have draw backs. The black list has more drawbacks, IMO.

I realised long ago that there is only one other option to explore. If you're a scientist you can see why it makes no sense to only ever test one method. It's not good science to fret over a reversible change with no evidence whatsoever to support such fear uncertainty and doubt... Such FUD is a waste of time.
TIHan wrote:
Torr Samaho wrote: Did you read through the whole tracker discussion and say that the specific ideas we had won't help or are you just commenting on how you think account systems work in general?
I did not read the entire discussion all the way through (It is indeed very lengthy), but I did the read most of what was proposed. This will slow cheaters down, but it of course will not rid of them. There will always be a workaround. So my question with what was proposed, how will it fair against thousands of players?
re:scaling: I read the whole tracker discussion. This authentication method requires connection state to be maintained needlessly in Charon. It may well handle a thousand non malicious users depending on the hardware and bandwidth, but it's not very scalable or resistant to attack.

Instead of transmitting the shared secret, a scalable solution will deliver proof of the shared secret, such that the Server can validate that only Charon could have generated the proof of authentication without per Client connection requests to Charon.

The implementation in its current form is actually a Charon DDoS waiting to happen since all the Servers contact Charon immediately after receiving an authentication request... Servers ignoring IP ranges is pointless in the face of an auth flood, since the Client return IP address is not yet validated at such point in your protocol...

Too much trust is being placed in the IP address validity. IP addresses can be spoofed in UDP packets where a 3 way handshake is not performed. The Charon-Client handshake attempts such a handshake, but is flawed in that it does not authenticate Charon to the Client (It's bi-directional, but only one way -- only one end is authed).

See: TCP for an example of a 3 way handshake. Note however that recent advancements in security research obsolete the TCP handshake -- The port & packet numbering can be easily probed, and thus blind-jacked. The blind hijacker can not see the client responses, but the client will trust the malicious packet data instead of the valid packets. TLS or equivalent encryption is now recommended for all authentication.
[spoiler]I have recently been granted permission from the US Bureau of Information Security and Export Controls to internationally distribute one of my ciphers. It builds upon the security of any one way encryption algorithm, such as SHA1 or MD5, to provide two way encryption & decryption systems. Since you have a working MD5 algo, you may find it useful.

The JS code is now MIT licensed. Reimplementations should note the source or else face possible fines from the USBIS: They must know what registered cipher algorithm is used for your internationally exported encryption. If the cipher is modified you'll need to register the modified version yourself. If unmodified (compatible) then I'm able to alleviate others' registration requirements via simple citation of origin. Note: This is a ridiculous requirement, but easy to comply with. US Jurisdiction may not extent to you personally, but this site and your code repository hosts both have .com TLDs...

Encryption isn't necessary, but in your case it could be used to prevent certain types of MITM attacks. Hint: The shared secret to use for Client-Charon encryption would be the player password, and could thus be secured end to end sans PKI (asymmetric encryption / certs).

Edit: Clarified BIS regs. Also, just after posting this I placed the JS example implementation under the MIT license to further nullify any possible re-licensing issue (was BSD).[/spoiler]

Since Charon and Client already have a pre-existing shared secret (password), proof of such knowledge could immediately validate Charon and Client to each other with only 1 packet each direction, 2 packets instead of 4 per 'login' as used in your current system.

There are various other flaws as well. I'll not enumerate them all, but here are some of the easier to explain issues:

Mal (malicious hacker) runs a server, user attempts to connect. Mal now has everything he needs to anonymously DoA that user (denial of authentication). Mal poses as Charon(s), sending a flood of spoofed IP packets bearing incorrect auth responses to the Client; Client will attempt to authenticate again perhaps on different Severs, but immediately receives the incorrect secrets sent by Mal, and uses them in further auth attempts when connecting to other Servers, preventing authentication.

A valid Client IP address may be different as seen by Charon than it is seen by Server. One example is when Client and Server are both behind the same NAT (user runs a server on her local network, but can't auth to her own sever). Your system fails to address this issue, and treats such Clients as invalid IPs.

I don't mean to be discouraging, but unless you have a working knowledge of information security I wouldn't suggest you attempt to invent an authentication system. I'm only trying to keep you from needlessly wasting valuable time and causing additional stress to the new community.

I have previously laid out a workable protocol that addressed these concerns and more, including optional Server banning and scalability... It's unfortunate that such a cookie based auth system was opposed in the past, as it could have been easily extended with name & password checks and Master decentralisation (indeed, I specifically designed it with such future features in mind). If any have an archive of that discussion you may find it useful. (perhaps Eruanna might have a copy from the st.com vs st.net debacle?) For example: one Master heartbeat per Server allowed all Clients to be authenticated by the Server without additional traffic to Master (Charon)... Your new implementation requires the same equivalent "heartbeats" to be generated for each and every Client auth request in addition to the Server heartbeats themselves.

It's very... interesting, that such a system is now under welcome experimental development, when it would have been so strongly opposed in the past... The waste of time is abhorrent to me.
Last edited by VortexCortex on Wed Jun 13, 2012 4:26 am, edited 1 time in total.

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Master Policy Reforms

#34

Post by Torr Samaho » Sat Jun 16, 2012 2:04 pm

VortexCortex wrote: It's very... interesting, that such a system is now under welcome experimental development, when it would have been so strongly opposed in the past... The waste of time is abhorrent to me.
At lot of things changed since you disappeared (more than two years ago IIRC). We went open source and forked, just to name the two most far-reaching changes. You can't be honestly surprised that we are rethinking some decisions made under completely different premises, can you?

Anyway, we are still in the discussion phase, nothing has been decided yet.

VortexCortex
 
Posts: 27
Joined: Mon Jun 11, 2012 1:43 am
Location: Houston
Contact:

RE: Master Policy Reforms

#35

Post by VortexCortex » Sat Jun 16, 2012 5:46 pm

Torr Samaho wrote: At lot of things changed since you disappeared (more than two years ago IIRC).
To avoid being off topic I'll only point out that a lot of things changed when I "disappeared", and only recently have some of the changes been rectified.
Torr Samaho wrote: We went open source and forked, just to name the two most far-reaching changes. You can't be honestly surprised that we are rethinking some decisions made under completely different premises, can you?
I'm not surprised at all. Interested. I watched said changes as they occurred. The fact you forked has little to do with the issue at hand. If you'll recall: We were discussing the fact that the code would be open source, and the protocol I proposed was designed with this in mind. Indeed, we all agreed a more secure protocol would make it easier to open the source. I find it more peculiar than surprising that such a system has yet to be implemented.

I apologize if you find my presence abrupt, but given that several devs had read the protocol and overlooked quite blatant flaws I felt it would be irresponsible of me to not say anything; Especially since you're now under new management, and seem open to suggestion.

As I said, I've always believed there was only one reasonable thing left to do: Try a different method of authentication and see if it works or not.

To be perfectly clear: I am interested in the addressing of this issue.

Let's not get off on the wrong foot again. I won't mince my words. I meant exactly what I said. I've already forgiven your patronizing remark, now let's move forward shall we?
Torr Samaho wrote: Anyway, we are still in the discussion phase, nothing has been decided yet.
(emphasis mine)

I'm trying not to read into this, but this really is the heart of the issue.

A secure protocol to address Zandronum's specific needs will take time and energy to create. Who can justify spending time working on solutions that have no assured chance of being given a fair shot at success? Not I.

Personally, I believe the issue has been in discussion phase long enough (for more than two years, IIRC). I would suggest you all come to a decision to either leave the system as is, or to make a commitment to design and try another system. United we stand, divided we fall. I think it would be best if the dev team could all get behind either course of action.

Action or inaction. The choice is yours, but there is only one logical choice in my opinion: Action.

As a scientist I can't speak to the success or failure of untested methods, and suggest any undue fear and uncertainty about them be disregarded until after they're fully examined.

I'm of the opinion that changes to the master server system are needed, and in order for anyone to evaluate them properly they must be given a real chance to succeed.

Considering that a proposal may be fully backwards compatible with the current protocols (as was my prior proposal), and that any such changes can be easily reverted if found detrimental: What basis can their be for fear or doubt?

The first step in addressing an issue is to decide to address the issue. It's not clear that the Zandronum developers have decided one way or the other: Action or inaction. Thus, any who would venture to work upon a solution are at sizable risk of wasting their time. Who has time in life to waste?

Were my vote to count I would say: Let's do science to it!
Last edited by VortexCortex on Sun Jun 17, 2012 2:08 am, edited 1 time in total.

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Master Policy Reforms

#36

Post by Torr Samaho » Mon Jun 18, 2012 8:11 pm

VortexCortex wrote: Let's not get off on the wrong foot again. I won't mince my words. I meant exactly what I said. I've already forgiven your patronizing remark, now let's move forward shall we?
Alright, I possibly read something between the lines of your post that wasn't there. Sorry about that. So let's move forward :smile: .
VortexCortex wrote: Considering that a proposal may be fully backwards compatible with the current protocols (as was my prior proposal), and that any such changes can be easily reverted if found detrimental: What basis can their be for fear or doubt?
The only basis for fear is that fundamental changes (even though technically reversible) may have irreversible effects. For instance, if players hate the new system enough to leave, reverting to the old way does not necessarily bring back these players. I don't say that we shouldn't risk this, I just want to point out that there is more to lose than just the time we put into the development of the system.

BTW: Do you still have a copy of your prior proposal?

Anyway, I think this is something not only the developers should decide, but also the administrators and moderators. The latter are the people who will have to work with the system.

VortexCortex
 
Posts: 27
Joined: Mon Jun 11, 2012 1:43 am
Location: Houston
Contact:

RE: Master Policy Reforms

#37

Post by VortexCortex » Tue Jun 19, 2012 12:38 am

Onward!

That's a good point about losing players. Risk is associated with any change, the best one can do is mitigate the risk as much as possible. Certainly you'd want to "beta test" any such system along side the current system before trying it as "production" ready, and be prepared to revert at the first hint of trouble.

The recent master server outage shows the community could be made ready to respond quickly if any sort of disaster strikes. It seems no matter the difficulties many folks keep coming back. This doesn't mean fear about harming the community is unfounded. You're right to be cautious. Being careful is key.

I don't think time put into developing such a system would be a waste; Worst case scenario it would somewhat settle the matter. I think it would only be a waste to develop the system and not test it. IMO, in order to warrant development the devs / mods / hosts need not agree to adopt the system outright; They'd only need to agree to test such a system and evaluate its adoption. If no one agrees to test it, then it's really not worth it.

I think server operators should always have the choice of which set of rules to follow, including their own rules. I see an account based system as giving more options to mods and server admins. The ultimate effect should be to reduce reliance on IP banning, thus alleviate some range-banning issues. To ease any additional management issues, tools could be provided such that managing text files directly wouldn't be the only option. Thus, the end result should be even easier to maintain than the current system.

Though it would need a re-engineer, the ban testing tool pre-alpha already showed improvement over the current banlist & exemption system. Eg: one can test the changes to ensure they work correctly before applying them, and temp-bans auto-expire without further action. You may note the User and Auth fields present in the system... A planned feature was to let moderators give a player caught in a range-ban an account+password, that would have been the bootstrap into Account based authentication. Eg, accounts could then be migrated to via the following rule:
[Ban] IP: *

Accounts would open the door for more players options as well, eg: Stats K/D & Win/Loss ratios, leaderboards, ignore lists, etc.
Torr wrote:BTW: Do you still have a copy of your prior proposal?
Unfortunately, no. I'd have posted it if I could. I had used the dev thread as my working documentation. I do remember some details, and that the system was built upon fundamentals of info. security and network scaling. Thus, a similar, if not exact, system would be created were I to attempt another solution given the same problem space. The prior system was completely reliant on IPs & rDNS. The addition of accounts could have been bolted on later, but their inclusion at the outset would simplify several issues.

Another factor in time to develop in a community arena is ensuring others understand the system, and why it would be secure. I wouldn't expect anyone to trust an auth system or encryption method unless it's theory was documented and explained, not just in the form of source code. This is also necessary to ensure the success of interoperability and future maintenance -- though once in place it would likely be as easily maintained as your current master server code is.

Were a new authentication system to be planned, which forum or tracker discussion would be the best place to begin assessing requirements and collaborating on a solution?
Last edited by VortexCortex on Tue Jun 19, 2012 1:46 am, edited 1 time in total.

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Master Policy Reforms

#38

Post by Torr Samaho » Tue Jun 19, 2012 8:15 pm

VortexCortex wrote: Were a new authentication system to be planned, which forum or tracker discussion would be the best place to begin assessing requirements and collaborating on a solution?
I think the best place to start would be a fresh ticket on the tracker. I will let you know once I have a clear indication whether the administration wants to give a radically different system (whitelist instead of blacklist) a chance. It may take a little till this is decided. Personally I think it's a good time to do something like this, but as I said above, it's not only my decision (and IMHO it should not only be my decision).

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Master Policy Reforms

#39

Post by Torr Samaho » Sun Jul 22, 2012 7:02 pm

VortexCortex wrote: The first step in addressing an issue is to decide to address the issue. It's not clear that the Zandronum developers have decided one way or the other: Action or inaction.
Alright. It took a bit, but I discussed this with the admins and mods and we are willing to give a whitelist based system a real chance :). Please create a tracker ticket so we can get the technical discussion started.

Llewellyn
Forum Regular
Posts: 578
Joined: Mon Jul 02, 2012 7:12 am

RE: Master Policy Reforms

#40

Post by Llewellyn » Sun Jul 22, 2012 11:31 pm

Torr Samaho wrote: Alright. It took a bit, but I discussed this with the admins and mods and we are willing to give a whitelist based system a real chance :). Please create a tracker ticket so we can get the technical discussion started.
Since you're moving forward on this, I have a couple concerns that I would like to apply (outside of the technical implementation of an AUTH system, which is why I'm discussing it here and not on any ticket.)

How will you handle new users (whether they are actually new or not.)
How will users who wish to remain anonymous to other players security be handled?
I can understand wanting security, but taking away anonymity isn't required.

Theoretical situation. Say a player (who isn't much liked by the community but never broke any rules) started aliasing and wanted an auth account, what would prevent those who confirmed they were who they were from leaking the information?

Locked