GUID registration system

[next_ghost]

I've been coding for a few weeks (and some university credits) and the result is a simple GUID registration system. Main features:
- automatic GUID registration and re-registration, good bye manual GUID changes!
- simple network banning in Tremulous server, GUID registration overrides network ban
- up to 131071 unique registrations (takes 3MB of hunk memory), may be changed at will as long as the number is prime greater than 256.
- fast hash table registration lookup, perfect replacement for current slow admin level search

It's far from completion (and not recommended for noncoders yet). I'll post more details tomorrow. For now, you can take a look here. The patch is written for SVN871, I'll modify it for current SVN later.

[tehOen]

we can store guid's in a database

[Caveman]

This BS takes care of the server-unique-GUID and the none-guid-using-fakers in what way?

Sheeesh, for someone that has some university credits you sure have no real clue.

[next_ghost]

we can store guid's in a database

Oh cool! And what are going to do with them to keep DHCP griefers off of you server? :roll:

This BS takes care of the server-unique-GUID and the none-guid-using-fakers in what way?

GUID registration is per-mod. If you want to run multiple servers using the same mod directory, it's not that hard to add a few cvars to set file names and have multiple registration lists in one directory.

No GUID = no connection from banned network. The permission test looks like this:

Code Select Expand

- Does the player have a GUID?
   - No => Is the player connecting from banned network?
       - No => Let them in
       - Yes => Kick them
   - Yes =>
Is there a registration request for their IP?
   - Yes => Register them and let them in
   - No =>
Is the player registered?
   - Yes => Let them in
   - No =>
Is the player connecting from banned network?
   - Yes => Kick them
   - No => Let them in

[tehOen]

erm you query the database for the guid ok? you can also store admin privileges
what is the problem with it?

[next_ghost]

erm you query the database for the guid ok? you can also store admin privileges
what is the problem with it?

Response time. 'nuff said. :roll:

[tehOen]

ugh you can import the stuff at server startup

[next_ghost]

ugh you can import the stuff at server startup

Then you end up doing the same thing I have already done.

[tehOen]

cooler than your poor text file

[Caveman]

No GUID = no connection from banned network.

This is where the shit hits the fan.
As long as the GUID is not included in the stock client you will have to ban by subnets, thus killing loads of innocent players.

Come up with a better system that has not been discussed already.

[next_ghost]

This is where the shit hits the fan.
As long as the GUID is not included in the stock client you will have to ban by subnets, thus killing loads of innocent players.

Come up with a better system that has not been discussed already.

When you get kicked because you're not registered and you connect from banned subnet, you'll get a message which says "Please register at foo.com/bar" (it'll be set using a cvar). All you need to do is writing a huge red text saying "You need this client to register (link)" on your website.

[sleekslacker]

Unless we have a means of identifying the registered entry/GUID to a unique person, this is still useless. In countries where the citizens each has his own National Identification Code, this is a possible solution.

Another way that has been discussed before is to delay the griefer each time his action is noticed. Activation by email can easily be circumvented. Someone ( BIG ) suggested a fee-per-registration method. Honestly, I think this is the best solution. I sure hope that if there is a surplus from that money, it would go to Mr Tyrant & Tyrantina plush toys for everyone .

[next_ghost]

Unless we have a means of identifying the registered entry/GUID to a unique person, this is still useless. In countries where the citizens each has his own National Identification Code, this is a possible solution.

Another way that has been discussed before is to delay the griefer each time his action is noticed. Activation by email can easily be circumvented. Someone ( BIG ) suggested a fee-per-registration method. Honestly, I think this is the best solution. I sure hope that if there is a surplus from that money, it would go to Mr Tyrant & Tyrantina plush toys for everyone .

We could use invite system like Gmail did. It's easy to keep track of invites and if somebody keeps inviting anyone who asks, simply revoke their invite rights.

[tehOen]

try to to think more realistic

[tuple]

Its unfortunate that everyone bitches about the GUID system, then bitches about anyone trying to do anything about it.  I wouldn't say that this is complete, but it certainly brings some interesting things to the table.  Do any of the complaining coders here realize that a successful identity system for trem will most likely not be built by one person, but will be assembled by pieces from numerous devs?  Please note that by successful, I do not mean that it does everything and makes toast for you.

The ability to do a subnet ban without locking out established players is a nice advancement, I'd say.  As well as multiple local servers being able to point to the same data.   Also, using hashed data to speed up the connection probably won't make a difference tomorrow,  but may in the future as it grants someone else cycles to build into.

Individuals using the stock client will still be able to connect to most servers, noone with a brain is banning class A networks (Though I'm sure someone will bring up a specific instance of class A banning now.)

Subnet bans are the most effective defense against griefers who've figured out DHCP, and subnet bans are used pretty heavily already.  This is the first thing I've seen that would allow players from banned subnets to join (not counting the great firewall of poland )  Aside from possibly being more informed as to why they are banned, stock clients are no differently affected than before, other than at least having the possibility of joining the server that they are subnet banned from, which they presently do not have.

No, it won't make a cake, but at least someone is starting to put the ingredients together.

Such a system cannot be made to be perfect, but it can be more flexible than the present system while still maintaining its present level of security.  You don't like its level of security?  Quit bitching and do something about it.

[Caveman]

Like I said, as long as the stock client does not have any guid system, all this thinkering is useless.

And tbh here is nothing new. Circumventing the sub-net ban with the guid has already been discussed and i faintly remember there to be a patch for it somewhere around.

Secondly what good does this system do when it is only used to communicate between local instances of the server?

The point is to cut down on grieving on the servers, therefor you'd need to come up with a way to communicate with other non-local servers. And that leads us right back to the failed attempt to build a DB that has all the data. I wont even mention the danger of false positives or worse, the wrong negatives.

So unless there is a way to really identify a single player across servers (again: NOT by IP) and a system that gives trustworthy warnings all this bickering is fruitless.

Heck, have a look at PunkBuster, they do that shit for a living and yet they fail miserably.
Don't you guys think that if id'ing a single player is possible, that we'd already have such a system somewhere around?

[sleekslacker]

While I agree that we should stop bitching at whatever ideas thrown at us ( some of them are pretty good ), it is still unclear to me how we can proceed from this work.

An invite system will keep a lot of new users out. The distribution of invites needs to be controlled and who do you trust that part of the system to ? The luser. Great. And there is also the 'not enough invites' issue plaguing Gmail (in it's early stage) and Demonoid.

What would be great is to come up with a viable solution, get at least 50% (75% is preferable) of the community to agree with it, put down a roadmap/todo list for the project completion, and write down the part that you are doing.

[next_ghost]

tuple: Bans don't use default network mask. Actually, you can set any mask you like from /32 (single IP) to /0 (none shall pass! :wink:). I was also planning to implement wildcard masks so you can for example ban 123.45.67.89 with mask 255.0.15.98.

Caveman: Current systems fail because they can't point J. Random User to get backport client. This system will point them to your website which will in turn point them to the client. They get the client, they register and everybody is happy. Except griefers of course

sleekslacker: There's no point in limiting invites. Either you're trusted and you can send as many invites as you want or you're not and you can't send anything. Anyway, you can do anything you like on your website. There's no registration front-end yet, just two example Linux apps that write server configuration files properly.

[Caveman]

next_ghost.
Your statement is plainly wrong.

a) the bug where the ban-msg is displayed only once upon a reconnect is still in play
b) a griefer _will_ come back with a new IP and new GUID and simply re-register his guid.
c) pointing to the backport is simply not enough for 08/15 players that get caught in this baning-mumbo-jumbo.

d) do not get hooked up on the existing guid to id a player, even with server-unique-guid it does NOT id a player, unless he wants it.

e) unlimited invites... what's the point of invites then? if you do not keep track of them or limit them, what's the point? (think about an avalanche here)

f) unless you make the registering mandatory for _all_ servers, servers that require it, will not see many new players, except for the regulars. Where is the incentive for new players to register if there are so many servers that do not require this?

f) are you sure with your subneting?

g) if you think about really baning people, do not use the build-in feature, it's faulty as hell and a determined griefer will get around it. Use iptables instead, or build an interface for it into the server-code, but beware of security issues.

h) and please do not use built-in apps that go around the server-console to modify the confs, you will fall hard with that.

Last but not least.

Before we go on about how to register and to keep griefers away, we should stick to the first point. The one on which everything builds...

A failsafe way to ID a player, one that can not be spoofed.

Until this is done in at least a rudimentary way, all further discussion is really pointless.

[tuple]

I highly doubt that there is a viable solution that will work for all servers.  The solution is not to recreate punkbuster or some OSS bastardization of it, the point is to give servers tools that they can use as their particular circumstances need.

Each individual tool can and will be shot down as ineffective for countless reasons as there is no monolithic solution that will fit all servers.  However, that does not mean that individual tools cannot be combined to create individual solutions to fit the needs of each server.

Would servers benefit from having local communications of this sort?  MG could benefit from it right now.  PT2 starts up when PT is full, having this data be synch'd between the two would be a benefit.  Can this code be modified to synchonize between disparate servers?  Between a central server?  If it could, could that server act as its own central repo and offer it out to other servers?  This tool may be a big hammer, can we use a chisel to create a different tool out of it?

It is not possible to have a reliable identity infrastructure based on GUIDs.  However, the GUID/IP combo is stronger than you may think.  Consider only allowing a particular GUID to have admin when coming from a particular subnet.  Again, you cannot rule out malicious activity, but it would greatly complicate the tasks of the GUID harvesters and GUID brute force attacks.

I'm sure that I could not even begin to envisage the little tweaks that could benefit various servers out there, but put all together those tweaks would very likely create a useful and powerful toolset.  That toolset will never exist if everyone keeps pointing out that each tool will not create a monolithic solution.

[next_ghost]

a) the bug where the ban-msg is displayed only once upon a reconnect is still in play

Subnet ban in my system is completely independent on any prior banning code. /reconnect or anything similar doesn't let you in.

b) a griefer _will_ come back with a new IP and new GUID and simply re-register his guid.

It takes at least one map reload before new registration requests are loaded. And if there're invites, it takes much longer before they get an invite (if they ever get one).

c) pointing to the backport is simply not enough for 08/15 players that get caught in this baning-mumbo-jumbo.

95 out of 100 players WON'T get caught.

d) do not get hooked up on the existing guid to id a player, even with server-unique-guid it does NOT id a player, unless he wants it.

That's the point. If they don't want to be identified, they won't get in.

e) unlimited invites... what's the point of invites then? if you do not keep track of them or limit them, what's the point? (think about an avalanche here)

To keep morons out, not to limit number of registered users.

f) unless you make the registering mandatory for _all_ servers, servers that require it, will not see many new players, except for the regulars. Where is the incentive for new players to register if there are so many servers that do not require this?

Registration is not required unless you're connecting from a banned subnet. Again, unless you ban 0.0.0.0 /0, 95 out of 100 users won't even notice there's some registration thingie on the server.

f) are you sure with your subneting?

Yes I am. Wildcard masks are commonly used except sometimes they're inverted to add some "fun" to configuration.

g) if you think about really baning people, do not use the build-in feature, it's faulty as hell and a determined griefer will get around it. Use iptables instead, or build an interface for it into the server-code, but beware of security issues.

Hello? Do you ever read or do you just drool on your keyboard? THAT'S WHAT I HAVE WRITTEN!

h) and please do not use built-in apps that go around the server-console to modify the confs, you will fall hard with that.

You didn't bother to download anything from that link, did you?

[Caveman]

tuple, I agree with you

But that is because you seem to take only the player in account that want to get ID'ed and those are not a problem.
Also narrowing the permission down from a subnet is a nice idea, even though I can only envision strange circumstances where this would be needed with the server-unique-guids.

The problem is to keep the server public as possible while at the same time ID'ing players that don't want to be ID'ed.
Mandatory registration will lead to less players if not _all_ server use it and to get that...

Making data available for more than one local server has also been discussed before and dismissed as being undoable as it requires a heavy rewrite of the engine, due to the way the server handles it's confs.

If you really want a chisel, then there'll be no way around an active admin, as ID'ing an uncooperative player is impossible.
And forcing uncooperative players from ones server automagically can only be done by brute force with loads of collaterals.

[Caveman]

a) the bug where the ban-msg is displayed only once upon a reconnect is still in play

Subnet ban in my system is completely independent on any prior banning code. /reconnect or anything similar doesn't let you in.

That is not my point .)
If one gets banned, he gets a nice popup with the ban reason. If he (tries to) reconnect(s) he will only get the ban msg _one_ time after that the msg wil be "This server is for low ping only".

b) a griefer _will_ come back with a new IP and new GUID and simply re-register his guid.

It takes at least one map reload before new registration requests are loaded. And if there're invites, it takes much longer before they get an invite (if they ever get one).

Sorry, but that will only help you for exactly one game and then?

c) pointing to the backport is simply not enough for 08/15 players that get caught in this baning-mumbo-jumbo.

95 out of 100 players WON'T get caught.

See my point a) you plan on telling those with the ban-msg that they need the backport (and/or the registration) and they get that for exactly 2 seconds before the bug kicks in and they are left clueless as to why they can not connect.

d) do not get hooked up on the existing guid to id a player, even with server-unique-guid it does NOT id a player, unless he wants it.

That's the point. If they don't want to be identified, they won't get in.

Then why not use the Password-feature?
Players from a banned subnet will not get your msg due to the bug and only your regulars will care enough to actually register other players have incentive to do so.
This WILL solve the griefer problem on one server, yes...

Then why not make it more simple?
Just expand the PWD-feature to accept multiple Passwords which you hand out for every player that registers somewhere. So no need to tinker with guids and such, if one of those does grieve then just revoke his PWD and you are all set.

e) unlimited invites... what's the point of invites then? if you do not keep track of them or limit them, what's the point? (think about an avalanche here)

To keep morons out, not to limit number of registered users.

That will not work. again the avalanche problem. How can you be sure that someone does not invite a moron? Heck you can not even be sure that your closest friend has the same rules to identify someone that _you_'ll call a moron.

f) unless you make the registering mandatory for _all_ servers, servers that require it, will not see many new players, except for the regulars. Where is the incentive for new players to register if there are so many servers that do not require this?

Registration is not required unless you're connecting from a banned subnet. Again, unless you ban 0.0.0.0 /0, 95 out of 100 users won't even notice there's some registration thingie on the server.

And again, the Bug from my point a) hits.

g) if you think about really baning people, do not use the build-in feature, it's faulty as hell and a determined griefer will get around it. Use iptables instead, or build an interface for it into the server-code, but beware of security issues.

Hello? Do you ever read or do you just drool on your keyboard? THAT'S WHAT I HAVE WRITTEN!

Hello? you actually let a user modify the iptables? Or do you mean to tell us that you let the tremulous server runs as root?
How sweet of you to tell us your scripts are useless

h) and please do not use built-in apps that go around the server-console to modify the confs, you will fall hard with that.

You didn't bother to download anything from that link, did you?

[/quote]

Nope, as all third party apps that are not in the server-code are unusable. And there is just no way for me to let iptables fall under the rule of any user-script, just as there is no way I'd start any game as root.

Like I said "beware of the security issues" .)

[next_ghost]

That is not my point .)
If one gets banned, he gets a nice popup with the ban reason. If he (tries to) reconnect(s) he will only get the ban msg _one_ time after that the msg wil be "This server is for low ping only".

Ahh, THIS bug. We'll just fix it then.

That will not work. again the avalanche problem. How can you be sure that someone does not invite a moron? Heck you can not even be sure that your closest friend has the same rules to identify someone that _you_'ll call a moron.

Rule: don't give invites to anyone you don't know personally. If you do and they get banned, it'll be the last time you've sent invite to anyone.

Hello? you actually let a user modify the iptables? Or do you mean to tell us that you let the tremulous server runs as root?
How sweet of you to tell us your scripts are useless

No, I have written code that does the same thing as iptables inside Tremulous server.

[Caveman]

That will not work. again the avalanche problem. How can you be sure that someone does not invite a moron? Heck you can not even be sure that your closest friend has the same rules to identify someone that _you_'ll call a moron.

Rule: don't give invites to anyone you don't know personally. If you do and they get banned, it'll be the last time you've sent invite to anyone.

And then you finally have closed player base

[doomagent13]

That is not my point .)
If one gets banned, he gets a nice popup with the ban reason. If he (tries to) reconnect(s) he will only get the ban msg _one_ time after that the msg wil be "This server is for low ping only".

Ahh, THIS bug. We'll just fix it then.

I am pretty sure this is a matter of the client CONTINUEING to try to connect even after it has been denied.  A fix would require a client-side modification, probably to the client code itself.

I just had a thought to redo the guid creation system.  Get all the information you can about the hardware--speeds, capacities, serial #s, and anything else--and put through the guid-creator thing with the server's ip at the front.  Result = a computer and server specific guid.  Only problem would be if any parts get replaced.

[next_ghost]

All reasons in g_client.c:ClientConnect are clearly kicks, not connection delays. I'll add a little change of SV_DirectConnect to drop client with reason instead of letting them wait when QVM says no.

OR we could simply move the ping test after all other tests.

[sleekslacker]

Get all the information you can about the hardware--speeds, capacities, serial #s, and anything else--and put through the guid-creator thing with the server's ip at the front. Result = a computer and server specific guid. Only problem would be if any parts get replaced.

Still not convincing. The GUID produced using that method can be faked, although probably 90-95% of individuals wouldn't be smart enough to do that. On another look, this fails to identify multiple players on the same computer. Here, let me remind you of Evlesoa and his evil brother. In any case, the 5-10% smart-alex still have a chance to wreck havoc repeatedly once they discover how to fake the GUID.

I really like the idea of delaying these MOFOs instead of trying to totally get rid of them. The latter is impossible, in my opinion.


How it works:

1) All servers can optionally choose to use the new GUID database.
2) Servers using this DB will send any ban info it makes to the GUID server.
3) Each GUID entry may be generated using any front-end ( clan websites, other forums ). However there is only one GUID database server. The front end will forward the user information to the central server and the database change is reflected. Verification at the central server might be crucial.

And what Caveman said,

The one on which everything builds...

A failsafe way to ID a player, one that can not be spoofed.

is definitely a very important point. I would like to stress what I said earlier: fee-per-GUID is a good idea. If someone is willing to fork out $10 for 5 minutes of griefing, every time, then let him pay for his stupidity. Perfect player identification might seem unrelated to fee-per-GUID. I don't really understand what's between the two either.. but I think it has something to do with people not giving their ID just like that because he is the one paying if anything happens. Hooking someone's neck with money is usually a good security .

[Caveman]

For the sake of argumentation, lets say there is way of ID'ing a player.
That leaves us with the problem that eg PunkBuster has.
Who has the right to mark players so that they are in the DB and are barred from playing?
Who has the right to unmark them?
Who will be the arbiter?
Who will watch the watcher?

Oh and before I forget to ask it (again) who actually wants such a server?
I am not alone when I say that we will never adhere to bans coming from a central server...

[==Troy==]

maybe make it easier a bit? identify a computer that is used, not the player. Hardware bans, as it is called. Yes, I know that they can be easily spoofed as everything else :roll: but that is at least something else a player has to do other than find a proxy and change his guid (first one is done in 5 mins, second one in 5 secs, hardware spoof will take about half an hour)