Idea for a ban system

[CU|CUdyin]

Web of trust.

Instead of worrying about GUIDs and how to fake them, detect fakes and so on, use the web of trust model.

Every client and server (called entity in the following sections) gets a public+private key. Every entity can sign any other one, if and only if

The entity A wants to sign entity B (A trusts B)
B wants to get signed by A (B trusts A)

That way, a deconner would barely ever get enough signs on him. Now, you could go for some more or less fancy stuff like 'I don't want to let ppl with less than 100 signatures being able to build' (variant for signatures from specific entities would be also possible) or 'I don't want ppl with signatures from player C on my server' and so on.

[cephas]

I'm going to have to go with Dyin on this one.  That's a brilliant idea.  Also useful would be to allow players to sign each other: you could even implement useful clanning with this (although it would take some work) where people have to be signed by the clan to show the tag (or at least some way to see if they actually are signed).  

More importantly, you could ban anyone who has a signal/noise (players/deconners) ratio past a certain point, preventing easy large-scale sign farming.  You'd have to do something to keep the number of total player reasonable (one key per IP for a reasonable interval? - we don't want people setting up sign farms).  This would also provide an easy way to keep first-timers from building on crowded servers (although it'd be necessary if the server was full of them - something to think about).

Seriously, this is the best solution I've heard so far.

[n00b pl0x]

ok...but people could just inflate each others rankings unless there was a definite way of marking someone which leads us back to square one D:

[cephas]

I was mentioning the 'pharming' technique there.  This ranking wouldn't be for anything useful, other than a measure of trust by the server (you don't even need to show it publically).  What you're talking about involves very limited webs of trust - either legitimate players are signing deconners (shouldn't happen too often) or they have set up dummy accounts for the purpose.  Note that in the former case, I mentioned a limit on the proportion of bad players one can sign before one becomes listed as one (which also hampers farming).  More importantly in the latter case, the web of trust is far less direct (I think the PGP spec pays attention to this).

I'm not especially knowledgable in public/private keys, but this is still a good idea.  

[tuple]

I don't think of this thread like all of the necro's I've been seeing, as bsel2 was the last posting some time ago, and bsel2 returned to this thread to announce an update to the program he spoke of (and released) in his older posts.  Seems entirely appropriate.  In fact, it seems wise, so that those of us who missed the earlier portion of the thread can review if we so desire.

I abhor people who make constant suggestions about what to do with tremulous to "fix" things but do nothing to implement it.  However, I am also filled with self loathing, so here goes

I have always felt that a username/password solution built into trem that is optional for server operators is the best solution.  With a mysql backend (not built into trem .) an operator could have users sign up on a web page for a username password to access the server, or for advanced features like building or playing more than X (say, 2) matches in a row.  Or they could disable it entirely and run a fully public server.  With this, I could hook up with a server operator friend and we could share a mysql db, so deconner bans on my server would carry over to his.  The mysql DB would have to tell the server whether the user is allowed and what their admin level should be.

Unfortunately, my knowledge of C is as strong as my welsh, which is to say non-existent.

edit: much of this may be obsolete with mark deconstruct though.

[CU|CUdyin]

Also useful would be to allow players to sign each other: you could even implement useful clanning with this (although it would take some work) where people have to be signed by the clan to show the tag (or at least some way to see if they actually are signed).  

More importantly, you could ban anyone who has a signal/noise (players/deconners) ratio past a certain point, preventing easy large-scale sign farming.  You'd have to do something to keep the number of total player reasonable (one key per IP for a reasonable interval? - we don't want people setting up sign farms).  This would also provide an easy way to keep first-timers from building on crowded servers (although it'd be necessary if the server was full of them - something to think about).

Seriously, this is the best solution I've heard so far.

1st) I meant entity as being either client or server, so in the A signs B example, player signs player would be possible.

2nd) The best way to allow first-timers on a full first-timers server would be a small admin-mod like 'if there's no signed player, then give anyone the ability to build'.

3rd) Yes, it would be some effort, but if you're going to use something like OpenSSL, it would lower your problems a lot. I'm way too busy to do the programming-stuff for this alone, nor do I have the infrastructure to alpha/beta-test it.

Edit:
4th) To limit sign-farming, you could either use the above 'I don't trust anyone with that signer'-mod or, if you got fooled to sign some1, create a revocation certificate, so that your signature for his account would be rendered invalid.

Idea: Maybe there's some way to use the GNU PG infrastructure?

Edit 2:

I have always felt that a username/password solution built into trem that is optional for server operators is the best solution.  With a mysql backend (not built into trem .) an operator could have users sign up on a web page for a username password to access the server, or for advanced features like building or playing more than X (say, 2) matches in a row.  Or they could disable it entirely and run a fully public server.  With this, I could hook up with a server operator friend and we could share a mysql db, so deconner bans on my server would carry over to his.  The mysql DB would have to tell the server whether the user is allowed and what their admin level should be.

You should take a look onto Wonko's PotatoBot (admin-interface) that does run on Potato Patch.

[Undeference]

lol, obfuscated C in Tremulous...
Someone can always lie. If they couldn't fool the system that makes the id, they can bypass it. TBH, I'm much more interested in seeing a handshake system (that won't break the protocol) like discussed here. That of course is entirely unrelated, more about secure user authentication (for admin purposes) than preventing typical griefing.

If you want to completely prevent griefing, just make the server take over everything that could potentially be malicious. The server will randomly build and deconstruct structures. The server will control your shooting / biting / slashing / charging. Etc. Just let people sit back and watch the server feed for them. When they are accused of feeding (or deconning), they can always blame the server and be right.

[bsel2]

Ok, I have created the following scenario to get rid of the stealing of UIDs and signatures:
http://mitglied.lycos.de/vsteiss/files/tremulous/UID_Ticket.png

- The client receives a signed UID from the UID Server created out of data send to it.
- If the Tremulos client connects to a server with sv_suid 1 the server will request the UID.
- If the client has a UID the server reqests a ticket (I don't know, maybe the server can serve some random data to the client).
- The client sends his signed UID and data for the ticket the to the UID verifying server.
- The UID verifying server will check for valid signature and on success sign the (random) data.
- The client send the ticket (signed random data) to the Tremulous server wich will verify the ticket with the public key of the UID verifying server.

Alternatively I have also tought about a scenario to trust servers so we do not need a central server this would be - as you mentioned - Web Of Trust-like.

As you see I have tought about web of trust method too but I think it is way to complicated. You would have to write an easy to use tool (maybe a script works well) to do all the keying stuff for you. Espacally for the new users. But a big advantage is - if you could implement this for trem in a usefull way - you need no central server as we could use the PGP/GPG-infrastructure (e.g. key-servers to distribute keys and signatures).
And another problem beside complexity is: A user can created multiple key pairs and then you don't have a unique identification.

EDIT: I have uploaded the public key of the UID server so you may test the Tremulous server with signed UID patch if you desire.

[Paradox]

As for the GUID system we already have in place, it is too simpe. Tjw should add something like Railfence or AES instead of MD5. Both of these have secondary and teritary keys, for added security.

[bsel2]

As for the GUID system we already have in place, it is too simpe. Tjw should add something like Railfence or AES instead of MD5. Both of these have secondary and teritary keys, for added security.

Using another hash algorithem than MD5 will not solve the issue. You can change the guid when ever you want to. This is the reason why I created a tool to create a unique ID based on system information. It's a question of trust: If you do not trust the client and the client is creating the guid than you can't trust the guid.
Btw.: You can't compare AES to MD5. AES is a block ciphre and MD5 is a hash algorithm. Just for info: The UID created with uidcreator is a hash with 512 bit length.

[Stof]

As for the GUID system we already have in place, it is too simpe. Tjw should add something like Railfence or AES instead of MD5. Both of these have secondary and teritary keys, for added security.

Using another hash algorithem than MD5 will not solve the issue. You can change the guid when ever you want to. This is the reason why I created a tool to create a unique ID based on system information. It's a question of trust: If you do not trust the client and the client is creating the guid than you can't trust the guid.
Btw.: You can't compare AES to MD5. AES is a block ciphre and MD5 is a hash algorithm. Just for info: The UID created with uidcreator is a hash with 512 bit length.

What I don't understand is, since you cannot trust the client to create a truly unchangeable GUID, how can you trust it to create an unchangeable UID?

Besides, keep your stinking closed source program far away from y computer please  :evil:

Tremulous is GPL, it isn't so that you will now require a closed source program to run. Where is the source to your uidcreator? Also, it seems you staticaly linked LGPL libs which isn't allowed by the LGPL licence.

[bsel2]

What I don't understand is, since you cannot trust the client to create a truly unchangeable GUID, how can you trust it to create an unchangeable UID?

Besides, keep your stinking closed source program far away from y computer please  :evil:

Tremulous is GPL, it isn't so that you will now require a closed source program to run. Where is the source to your uidcreator? Also, it seems you staticaly linked LGPL libs which isn't allowed by the LGPL licence.

That's the problem: You cannot do it with Open Source. If I would know a possibility to do it in a free way, I would do it.

As the uidcreator is closed source the user needs a big effort to manipulate the programm or the data send from it, this is more trustworthy than a free program

Even if you use a build including the suid-patch you do not need the uidcreator to run Tremulous. You even do not need a text file including the signed UID.
Btw. Tremulous is GPL and I can implement what I want, and if I want a copy of Tremulous that can only run with my system it is up to me to implment this and nobody can stop me.. MhaHaahhahahahaha...

As far as I know static linking is allowed with LGPL but not with GPL. If I am wrong I will provide the old build format (it was dynamicly linked before).

EDIT: You can excange the public key I used easily. You can create a different solution, maybe use it to sell signed UIDs. This is infact the best trust level you can have... if you trust the signer

[Stof]

That's the problem: You cannot do it with Open Source. If I would know a possibility to do it in a free way, I would do it.

As the uidcreator is closed source the user needs a big effort to manipulate the programm or the data send from it, this is more trustworthy than a free program

Even if you use a build including the suid-patch you do not need the uidcreator to run Tremulous. You even do not need a text file including the signed UID.
Btw. Tremulous is GPL and I can implement what I want, and if I want a copy of Tremulous that can only run with my system it is up to me to implment this and nobody can stop me.. MhaHaahhahahahaha...

As far as I know static linking is allowed with LGPL but not with GPL. If I am wrong I will provide the old build format (it was dynamicly linked before).

EDIT: You can excange the public key I used easily. You can create a different solution, maybe use it to sell signed UIDs. This is infact the best trust level you can have... if you trust the signer

The thing I object the most is the ID generated from the user hardware. Also, MAC addresses are very easy to change so you are indeed giving the user a way to generate a lot of free IDs. Creating a closed source program to get such info and making that one mandatory to play trem is an absolute no from me. I'll not have to use a closed source program to play trem, all that to implement a flawed to begin with way to track the users.






But the whole user ID scheme authenticated from a central server is in my opinion very interesting and worth it. That way, you solve once and for all the weak GUID problem If it's just for that, it doesn't need to be closed source or obfuscated code.

Oh, and I know for sure that LGPL prevents static linking. Well, to be exact, it doesn't really prevent it. You can do what you want with the unmodified LGPL code as long as you give the user everything he needs to replace the LGPL code with anything else. For example, you give the binary and all the .o files used to build it so that the user can produce a new binary himself. It does make obfuscating the whole program harder like that though.

PS: and the GNU libc is ALSO LGPL so you cannot staticaly link that one either IIRC.

[::ThePredator]

Bsel, does your algorithm use hardware to generate the user key? If so that can be beat wasily using chroot (maybe time consuming but not exactly hard). I truthfully don't think that there will be a way to manage it without someone actually handing out keys in an IRC room, although storing info in an offsite db (although I am more of a postgresql fan than mysql) would be the best idea suggested.

[bsel2]

You are right I have to provide the object files if I link statically so I included it to the package.

I'll not have to use a closed source program to play trem, all that to implement a flawed to begin with way to track the users.

I know that guys which are using LinuxBIOS to boot their PC and free graphics cards drivers to run OpenGL games will not use such a closed source program. I respect this.

But the whole user ID scheme authenticated from a central server is in my opinion very interesting and worth it. That way, you solve once and for all the weak GUID problem  If it's just for that, it doesn't need to be closed source or obfuscated code.

I know. The part I added this year to the scenario (the "Verifying Server") does not need to be closed source.

Bsel, does your algorithm use hardware to generate the user key?

I'm sorry but if I would awnser this questoin I could also release the source code.

PS: Maybe it is possible to authentificate against the master servers. Does anybody know, how the master servers work?

[daenyth]

My god, this whole discussion is retarded. Software blocks for griefers only hinder honest players. The assholes will get around it anyway, and you make it harder for the good people to play.

THE ONLY EFFECTIVE SYSTEM TO STOP ASSHOLES IS TO PLAY ON SERVERS WITH SMART ADMINS

[bsel2]

As I have thought about preventing the signature stealing I would have to do something like a mini-Web Of Trust. So I ask you: Hey guys where are you?
Especially theCU|CUdyin. Your opinion for a good implementation is needed. As I do not want to implement something nobody likes.

Btw.: Admins do sleep.

[CU|CUdyin]

Warning: a load of techno-babbling follows :wink:

As I have thought about preventing the signature stealing I would have to do something like a mini-Web Of Trust. So I ask you: Hey guys where are you?
Especially theCU|CUdyin. Your opinion for a good implementation is needed. As I do not want to implement something nobody likes.

Btw.: Admins do sleep.

General stuff
-------------

"The enemy knows the system being used" -- Claude E. Shannon

You can always disassemble/reverse-engineer an application. If this point is happening, then your security can be screwed up.
Examples:
 1 commercial data-safe got owned a couple of years ago, when 1 person figured out, that the whole password-check for the encryption was done with an if-statement -- the password wasn't used to generate the key. An possible attacker had to only change 1 bit to unencrypt any data-safe protected with that software.

 There's a lot of secure encryption software out there, that is using 'custom high-security 5,000,000-bits' algorithm. It does usually figures out, that the so-called encryption is nothing else than a simple xor. Such sort of software is getting called snake-oil (refer to http://www.schneier.com/crypto-gram-9902.html for further details of how to detect such software).
See also http://en.wikipedia.org/wiki/Kerckhoffs'_principle for yet some other principles.

Use an open development approach.
Best example for this strategy was/is the AES-selection. Multiple teams with public known and specified algorithms tried to brake their own as well as the algorithm(s) from other parties.

Use trustworthy pre-built components.
The old saying 'the chain is only as strong as its weakest link' does also apply to security. F.e., if you've all of your sensitive data encrypted with a password that is easy to be guessed, then you do only slightly improve your security. Most security-breaches come from a problem with the protocol, not with the algorithms themselves. Best example the above stated data-safe. Yet another good example is the design of the X.509-certificates, which is nullyfying some attacks due to some specific details of its block-structure.

Specific to trem/this thread
----------------------------

If you go for a web-of-trust, you'll get a thing like onetime-IDs for free on top of it.
You don't have to do the whole web-of-trust or ID-thing within trem itself. You could also go for typing-in that ID as soon as you're going to join a server, and could distribute the IDs through a website. A server would only have to contact the server and check through a secure way, that the IDs valid. Security-problem at this point is, that an attacker could try a brute-force attack, i.e. guessing a load of possible IDs per second and using the one that is valid. As long as the IDs are some sort of strongly non-linear (so not 0x0000 followed by 0x0001 followed by 0x0002 ...), then the chances are small (but keep the birthday-paradoxon in mind). You can also block a certain IP for a while, if said IP is trying way too many requests per time-scale. Problem here would be a possible DoS through malicious ppl hopping onto specific servers. The DoS would affect the server as well as legitimate players, but not anything else.

I'd suggest alot of reading security-specific literature, esp. about protocols and standards. The IMO best point of starting with it is still Bruce Schneier's "Applied Cryptography" while some of the algorithms therein (namely DES among others) are somewhat aged and outdated.

Specific to bsel2's mini-web of trust:
--------------------------------------
Go for batts-are-included packs like OpenSSL (or maybe find a way to interface with GnuPG). Alot of applications are using the OpenSSL-libs so you can suppose that they're tested (in case of AES/Rijndael, it was even certified).
Also make sure to use a peer-review / open-source approach. The more user's the more brains thinking about/finding actual problems.

Btw.: Admins do sleep.

I'm obviously not asleep, while I'm still maybe dreaming about trem's (hopefully) upcoming web of trust  :wink: Seriously, I know alot of admins trying their best to keep the game fun, but sometime's it's only that much annoying, that you're going to say 'f**k it' and then doing something different like mowing the lawn.

[bsel2]

As you can see, if you have a look at the patch, I am using GnuTLS (instead of OpenSSL). It's easy to use and free. It has x.509 support and a simple OpenPGP interface. You cannot use the whole trust model of OpenPGP so we would have to use e.g. GnuPGME to implement the web of trust.
Admins can be identified easily and in a secure way with the signed UID method. But infact there is already a secure way to identify admins: Using one cl_guid per server. The only issue still present is the unique identification of the players. This was the only reason to create the uidcreator.

Current status is: The player can change the value of cl_guid by deleting one file and restarting the game. And bans based on IP address do only work with a statically assigned IP address, but who is using this? ISPs mainly assign a dynamic address to private customers. If the cheater/griefer reconnects he will get a new IP address. The ban is useless at least after one day if there is a 24h disconnect of the ISP. Maybe we just need to wait for IPv6 and everything is solved...
The question is: How can we distribute the PlayerID in an easy and trustworthy way without making it complicated for new players to join the community?
There were already made some suggestions in this discussion:
 - marginal fee
 - E-Mail address


Web Of Trust
-----------------
Regarding to the above description of getting around bans based on cl_guid and IP address the only way granting access to a server for me is the deny-accept-method. Only allow players with a trustworthy key to join. So you need a public key signed by a person the server owner trusts.
Let's think about this:

There are different servers with different owners:
ServerA belongs to Person1
ServerB belongs to Person1
ServerC belongs to Person2
ServerD belongs to Person3
ServerE belongs to Person4

The owner trust relation:
Person1 trusts Person2
Person2 trusts Person1
Person2 trusts Person3
Person3 trusts Person2
Person1 does not trust Person3
Person3 does not know Person1
Person4 is unkown by all.

The result:
As Person3 trusts Person2 and Person2 trusts Person1 you can play on ServerD with a key signed by Person2 or Person1.
If my key is signed by Person3 I may play on Server2 and Server3 but not on Server1 and Server2.
You can only play on ServerE if you contact Person4 to let him sign your key.

This is complicated, is it not?
And what if the turst is based on liking and disliking eachother?

Another question is: How do you distribute changes on the key regarding the trust?
Ok, the awnser to this question is: Use the existing key servers.


I still prefer the    x.509 infrastructure.

Specific to trem/this thread
----------------------------

If you go for a web-of-trust, you'll get a thing like onetime-IDs for free on top of it.
You don't have to do the whole web-of-trust or ID-thing within trem itself. You could also go for typing-in that ID as soon as you're going to join a server, and could distribute the IDs through a website. A server would only have to contact the server and check through a secure way, that the IDs valid. Security-problem at this point is, that an attacker could try a brute-force attack, i.e. guessing a load of possible IDs per second and using the one that is valid. As long as the IDs are some sort of strongly non-linear (so not 0x0000 followed by 0x0001 followed by 0x0002 ...), then the chances are small (but keep the birthday-paradoxon in mind). You can also block a certain IP for a while, if said IP is trying way too many requests per time-scale. Problem here would be a possible DoS through malicious ppl hopping onto specific servers. The DoS would affect the server as well as legitimate players, but not anything else.

Sorry but I do not get what you are talking about here.

[cephas]

It might be a good idea to start with Wikipedia (the source of all useful knowledge )

• Web of Trust
• Public Key Infrastructure

These are two different approaches to this problem.  I think that the web of trust idea is better because it doesn't require any central server (this is Open Source software, and we're known for being cheap like that).  We've had enough trouble with the trem master server, we don't need a seperate GUID one.

I'd contend that ultimately, the solution to the GUIDs aren't tying them to the user/hardware as closely as possible, but to make generating a new one a less-than effective method of griefing.  If building is only allowed for a certain trust level, deconners will have to not only generate a new key, but also get trust for it.  I guess bans could still be evaded, but you could establish some evil autorevoke stuff (like automatically revoking a key from a client IP that has been banned - which would make evading more difficult).

[CU|CUdyin]

Specific to trem/this thread
----------------------------

If you go for a web-of-trust, you'll get a thing like onetime-IDs for free on top of it.
You don't have to do the whole web-of-trust or ID-thing within trem itself. You could also go for typing-in that ID as soon as you're going to join a server, and could distribute the IDs through a website. A server would only have to contact the server and check through a secure way, that the IDs valid. Security-problem at this point is, that an attacker could try a brute-force attack, i.e. guessing a load of possible IDs per second and using the one that is valid. As long as the IDs are some sort of strongly non-linear (so not 0x0000 followed by 0x0001 followed by 0x0002 ...), then the chances are small (but keep the birthday-paradoxon in mind). You can also block a certain IP for a while, if said IP is trying way too many requests per time-scale. Problem here would be a possible DoS through malicious ppl hopping onto specific servers. The DoS would affect the server as well as legitimate players, but not anything else.

Sorry but I do not get what you are talking about here.

Client A wants to join server B:

A does a DH with B,
each side signs the key with their own signature and sends the result to the other one. Each side validates the received signed key. --> session UID, could be tied to server and/or IP of client.

This thing is pretty useless with a web-of-trust. The scenario would also be possible with a uid-server C.

Regarding your patch-file: y not only #include-ing the headers instead of copy-n-paste (never used GNU TLS, so wondering)?

[bsel2]

Regarding your patch-file: y not only #include-ing the headers instead of copy-n-paste (never used GNU TLS, so wondering)?

I did this because of the static libs for win I did not add yet. I also forgot to add the COPYING for GnuTLS.

We've had enough trouble with the trem master server, we don't need a seperate GUID one.

Maybe we can use the master for this?

I'd contend that ultimately, the solution to the GUIDs aren't tying them to the user/hardware as closely as possible, but to make generating a new one a less-than effective method of griefing.

With the current uidcreator the user is not addicted to the hardware or system. He can copy the signed UID to another PC. In principle it's the same like cl_guid but generated outside of Tremulous.

EDIT:

I think that the web of trust idea is better because it doesn't require any central server (this is Open Source software, and we're known for being cheap like that).

The x.509 infrastructure does not need a central sever either. You just need a certificate you trust.
And as it is all about "Does the server trust the connecting player?" web of trust seems to me like an overkill. You need anyway to restrict the usage of web of trust: You would not check the trust level between the players but between the servers and the server and the players (the admins are the server). If you would also check the trust between the players, someone could easily do a DoS attack or similar things.