Page 2 of 4
Posted: Mon Nov 14, 2011 4:15 pm
by SP4WN
The client side and ID control can run just as it does now, with fingerprinting and such.
That doesnt take away from the fact that hacking a clients security is much easier than a server.
Posted: Mon Nov 14, 2011 4:55 pm
by Dorjan
The thing about bans, is that the whole point of them is to make the players learn to get on and remove the trouble makers.
If they (like Frag or that other guy whatever he's called) decides to STFU and play after a ban, then why not? They've clearly stopped being an idiot and decided to play.
Circumventing bans in FTP games is normal, but then that's fine so long as they learn or the @Alleg's keep banning away

lobby booting if they're not there.
Also, with more players (where this becomes an issue) will mean more enforcers etc
It's a self sorting situation
Posted: Mon Nov 14, 2011 6:23 pm
by Archangelus
I volunteer to be an enforcer. Whoever doesn't insta bend to get a kiss in da butt, will get insta banned.

Posted: Mon Nov 14, 2011 6:27 pm
by fuzzylunkin1
As far as I know, MonoASGS neither increases nor decreases security. It's just a different implementation. Of course, YP would have to explain/confirm everything. Apparently Pook did a good job at obfuscating the code

.
Posted: Tue Nov 15, 2011 4:31 pm
by peet
Agree, bypassing a ban is a national sport. While development is in progress for the improved ASGS, it would be nice that an enforcer can tell a gameserver to "stop communicating" with said player. At least it will prevent that said enforcer will get a *facepalm* from a non-reacting game client. I can imagine not many people want to enforce a game this way:
gamer: blah blah blah swear swear swear
enforcer: stop those insults or be kicked
gamer: trolololo swear blah blah spam spam
enforcer presses kick button
gamer client: hey, a request for a kick, *ignore*
gamer: trolololo tee heee
enforcer grumble curses yells at TE
Posted: Tue Nov 15, 2011 6:07 pm
by Dorjan
peet wrote:QUOTE (peet @ Nov 15 2011, 04:31 PM) Agree, bypassing a ban is a national sport. While development is in progress for the improved ASGS, it would be nice that an enforcer can tell a gameserver to "stop communicating" with said player. At least it will prevent that said enforcer will get a *facepalm* from a non-reacting game client. I can imagine not many people want to enforce a game this way:
gamer: blah blah blah swear swear swear
enforcer: stop those insults or be kicked
gamer: trolololo swear blah blah spam spam
enforcer presses kick button
gamer client: hey, a request for a kick, *ignore*
gamer: trolololo tee heee
enforcer grumble curses yells at TE
Exactly, everything should be server side.
Posted: Wed Nov 16, 2011 8:24 pm
by Tigereye
You guys are absolutely correct, but unfortunately Allegiance doesn't work like that.
We can get Allegiance to kick a player, but they can log back in with another name.
We can get a gameserver to block communications from a specific IP, but a proxy can be used to get a new IP.
While enforcing security from the server's side is preferable to enforcing it from the client, the server still relies on what the client is telling it.
On Windows machines, ASGS tells the server information about a user's callsign and linked callsigns so the server can make decisions with the limited info it has to let the user in or not.
On Linux machines, it is up to whoever wrote the Linux client to make sure they are providing the appropriate information to the server.
That's all I meant in my post above about 'moderating.'
When it comes to making Allegiance more accessible to all by adding features, porting it to other platforms, and other technical wizardry - we all stand to benefit from the fruits of our members' labour. But their help could make it easier for malicious players to ruin everyone else's fun unless their code enforces the same rules for Linux players as are enforced on Windows players. I'd hate to see a "good thing" have "bad results" because of an oversight.
--TE
Posted: Wed Nov 16, 2011 9:59 pm
by Dorjan
Tigereye wrote:QUOTE (Tigereye @ Nov 16 2011, 08:24 PM) You guys are absolutely correct, but unfortunately Allegiance doesn't work like that.
We can get Allegiance to kick a player, but they can log back in with another name.
We can get a gameserver to block communications from a specific IP, but a proxy can be used to get a new IP.
While enforcing security from the server's side is preferable to enforcing it from the client, the server still relies on what the client is telling it.
On Windows machines, ASGS tells the server information about a user's callsign and linked callsigns so the server can make decisions with the limited info it has to let the user in or not.
On Linux machines, it is up to whoever wrote the Linux client to make sure they are providing the appropriate information to the server.
That's all I meant in my post above about 'moderating.'
When it comes to making Allegiance more accessible to all by adding features, porting it to other platforms, and other technical wizardry - we all stand to benefit from the fruits of our members' labour. But their help could make it easier for malicious players to ruin everyone else's fun unless their code enforces the same rules for Linux players as are enforced on Windows players. I'd hate to see a "good thing" have "bad results" because of an oversight.
--TE
Although I agree, it seems like a false economy to run things like they are now. In the sense of "iron fist security", although we have nothing to offer anyone to keep their accounts ofc apart from "rank". The security for checking the core files for example. It's a bit weird, why does the client get to boss the server around in the sense of "i'm travelling 1000ms" when you're not allowed, and it's impossible to do so.
I'm no expert on netcode but I know how current games work and it just seems like Alleg works by the server going "derp OK!" to _anything_ the client tells it. So ofc, with this being the way the servers work we can't afford not to have an asgs style enforcement although, as we know, even that is by-passable.
Posted: Thu Nov 17, 2011 2:39 am
by TurkeyXIII
Not anything. There are some things that the server knows are wrong, like receiving a 'boot player X' message from somebody who isn't the commander.
Probably not enough things, though. It would be possible to add a few checks, like if an AB missile comes from a scout or if a fig gets above the maximum theoretical boost speed + aleph exit speed. But even some things like acceleration and/or teleportation can't be assessed by the server because it needs to accommodate for lag, and other things like lead indicator aren't seen by the server at all.
There was a thread discussing security solutions in the leadup to the CSS project, and the people with the brains to implement the damn thing decided on a similar concept as ASGS. If it's good enough for them, it's good enough for me.
Posted: Thu Nov 17, 2011 3:41 am
by Dorjan
TurkeyXIII wrote:QUOTE (TurkeyXIII @ Nov 17 2011, 02:39 AM) Not anything. There are some things that the server knows are wrong, like receiving a 'boot player X' message from somebody who isn't the commander.
Probably not enough things, though. It would be possible to add a few checks, like if an AB missile comes from a scout or if a fig gets above the maximum theoretical boost speed + aleph exit speed. But even some things like acceleration and/or teleportation can't be assessed by the server because it needs to accommodate for lag, and other things like lead indicator aren't seen by the server at all.
There was a thread discussing security solutions in the leadup to the CSS project, and the people with the brains to implement the damn thing decided on a similar concept as ASGS. If it's good enough for them, it's good enough for me.
ah.