Tremulous Forum
General => General Discussion => Topic started by: CoD on June 25, 2006, 10:06:40 am
-
I have an idea for the banning system, but I don't know if it woud work well.
I read in this forum about a unique-id banning system, based on an unique id instead of ip or username.
This would be a very good starting point, but people would always be able to change their unique id because tremulous is open source and so we have whole access to the code.
But... if we'd use some cryptography changing the unique-id would be still possible but very hard to do.
I have 2 options: one faster but weak and the other a bit more slow but stronger.
Faster and weak
Unique-id is used to encrypt some files on your tremulous base folder.
Nothing customizable (like cfg files) but something needed.
If you change your unique-id you'd not be able to play trem anymore, because trem wouldn't be able to decrypt these files.
Weak point: A cheater has just to find the encryption routine and decrypt and re-crypt his files.
Slower and strong
Use sign.
We could generate a "main tremulous" key pair.
The public key should be distributed with the game, while the private key should be kept on one centralized server.
In the installation processes or maybe at the first game start, trem should generate a unique-id, connect to the central server and have the unique-id signed with the private key of the tremulous team.
I'm not talking about encryption, I'm talking about signing: every server would be able to see the unique-id in plaintext and ban it (if needed), but every-server would also be able to verify the signature of the unique-id using the public key of the main trem server, making unique-id cheating nearly impossible (apart form uninstalling and re-installing trem completely)
The only weak point is the time used to verify a signature before logging on a server, but this is the stonger system I can think about.
-
I fail to see how this would stop someone just registering a new id?
-
This is the problem, I know.
But getting a new id and having it signed wouldn't be as easy as changing name.
Most people won't try... I think.
-
The idea of signing and encryption is a good one but must be implemented in another programm that is not even OpenSource I think. The program should use some hardware identifications to create the unique ID, send them encrypted to a server and receives a signed unique ID.
Problems appear when changing hardware. But well... as the most are using Win (I guess) they are used to it ;)
Image of idea (http://www.mitglied.lycos.de/vsteiss/files/tremulous/UID.png)
-
The only reason GUID systems work at all is because each GUID has some monetary value associated with it. In other words, you can't just hand out GUIDs for free because then there is nothing stopping somebody with a banned GUID just grabbing a new one.
The only way to make such a system work is to actually sell the GUIDs, if only for a nominal fee. I'm fairly unconvinced Tremulous has a large enough playerbase to make this feasible though, especially if the number of donations (http://sourceforge.net/donate/index.php?group_id=14890) we have received so far is anything to go by</subtle> ;).
-
The only reason GUID systems work at all is because each GUID has some monetary value associated with it. In other words, you can't just hand out GUIDs for free because then there is nothing stopping somebody with a banned GUID just grabbing a new one.
The only way to make such a system work is to actually sell the GUIDs, if only for a nominal fee. I'm fairly unconvinced Tremulous has a large enough playerbase to make this feasible though, especially if the number of donations (http://sourceforge.net/donate/index.php?group_id=14890) we have received so far is anything to go by</subtle> ;).
If the UID creator is a proprietary programm, you can create a unique ID for free.
The creator calculates a value related to some hardware components or the operating system. This value is send encrypted to the UID server. The UID server calculates an unique ID and signes it with a private key. This signed UID is send back to the creator.
Now the Tremulous client has to send the signed UID to the Tremulous server. The server verifys the signed UID using the public key of the UID server.
-
What's to stop the user feeding the closed source fingerprint creation program with false information (about hardware or whatever data source it uses)? Not a lot.
-
First of all it will stop these base destroyers. I don't think they will reverse engineer this.
Also I don't think it is simple to get the whole information which the programm uses to calculate the fingerprint.
I know, it is only a question of time. But that's the same with all anti cheat programs, too.
Nothing is secure... and trust is a weakness.
-
TKers, cheaters and lamers of this variety will not go through all the trouble. A lot of them really are just early adolescents getting off on screwing with other people with little to no effort. Forcing them to do something as complicated as fake their hardware to get a new GUID will stop pretty much all of them. The one dedicated bastard with a grudge and some knowledge? Well, you can't win 'em all. But with this, it'll at least be easier.
Trem's greatest weakness against malevolent players really is the fact that nobody is uniquely identifiable. Even if you made GUIDs free and exceptionally easy to obtain, it'd still be better than having no universal identification system at all.
-
just kick/ban by IP :roll:
-
IP ban doesn't work for dynamic connections like mine and it's extremely unuseful for shared ip connection like (in italy) fastweb italia.
I don't know if this exists also in other countries, but here we have fastweb customers sharing 2 or 3 IPs when connecting to the internet (fastweb is a WAN)
If you ban 1 ip you'll ban thousand of possible players.. is this correct? I don't think so.
Let's not forget that remulous is open source: we don't need a super-strong system capable of lasting forever because we don't rely on big releases.
Just implement a guid and then we'll go on changing the code in new versions: open source is strong because it can be adapted day by day.
If somebody will find a way to cheat with the guid system, we could make it stronger.
-
The best way to actually ban someone, is not to have it ban based off of crap that can be recreated, but to be banned based off of Volume Id and MachID. Volume ID is the ID of your harddrive, and although it can be changed, with the backup of MachID, it is practically fail safe. The only way for the person to bypass the ban, is to essentially get a new Nic Card, and change there Volume ID. Which is a lot of trouble...and if they do it again, ban them again...eventually they will give up. It becomes too costly.
-
The only reason GUID systems work at all is because each GUID has some monetary value associated with it. In other words, you can't just hand out GUIDs for free because then there is nothing stopping somebody with a banned GUID just grabbing a new one.
The only way to make such a system work is to actually sell the GUIDs, if only for a nominal fee. I'm fairly unconvinced Tremulous has a large enough playerbase to make this feasible though, especially if the number of donations (http://sourceforge.net/donate/index.php?group_id=14890) we have received so far is anything to go by</subtle> ;).
if its something like $1-3 then I'm all for it [I'm a cheap ass]. Make GUID check optional server side and add icon to server list to show which ones are "secured". This will let newbies play for free, and us more safe. Also with GUID (crypto, no sending in the clear, only hashes handshake with ONE central server) it WILL be possible to ban from logs, maybe even central GUID server could ban ppl acording to statistics (or flag gfiefers and send daily mail to admins)
-
That would split the game into two seperate communities - those that pay and those that dont. And tbh, I imagine it would be fairly rare that enough "secure" people were online to actually get a game or two going on the secure servers. Everyone would just play on the unsecured servers anyway, and it would be back to square one.
-
oh RLY? cos the same can be said about american servers, that onyl americans play trem so european servers would be empty all the time, or that everyone plays old maps so beta map DB@ would be empty all the time, or that there are only so many players yet so many servers, and pll will play in small groups only ..
it WILL work. 1-3 bucks is small enough even for such a cheap ass like me, but to much to spend for a 1-2 minutes of griefer "fun" (and you can trace the money from banned GUIDs)
-
Completely different. There is no barrier between european/american players and servers and no barrier between custom maps/non custom maps.
I severely doubt enough people would pay for a UID to make forming a seperate set of servers viable, especially since it doesnt really get you anything for your money.
-
I would just like to go on record as someone who would pay for a unique ID system.
-
it would give my 2 things, one I would donate that way, two I would be sure that griefer pays for his stupidity
-
What many of you seem to be forgetting is that since Trem is open source it would be easy to compile a version that sent fake info to the server.
-
I will not support a game that was free, and then turned its back on the community to make it pay to play. Look at Infantry, the game was free, then went to pay...they also had servers that where Free, with restrictions. You will kill this game if you do anything that requires money. I would also like to note that this happened with a game that I played...even though it was a "small" amount of money, no one would do it....it had like 100 people, as compared to 10,000. Then the public made an effort to make the game Free, and we successfully where able to do it.
Your best bet is to do what I suggested in an earlier post. It has worked for us very much so.---http://tremulous.net/phpBB2/viewtopic.php?p=9051&highlight=#9051--- is the post.
-
Its imposible to design a system that will work for 100% or idiots. But you can design a system that will work for 95% of idiots and that is enough.
I think that 95% system is uniqueid, so banning will work with something much usefull than the IP.
A option can be to use a "optional" safety module, like Fuhquake do and other quakeworld engines do. This module will provide punkbuster features.
-
I have finished a test program to 50%. I will post it soon, so you can see, the signed UID is possible and not easy to crack. And I hope somebody will try to fill it with manipulated data.
I do it only for GNU/Linux. If it works and the responses are good, maybe I will try a Win32 client too.
-
Here it is! The first testversion of the uidcreator. GNU/Linux only.
UID-Creator (http://www.mitglied.lycos.de/vsteiss/files/tremulous/uidcreator.tar.bz2)
Please read COPYING and LGPL before using ;).
The uidcreator is using GnuTLS for encrypted data transfer. So I shipp it with file libgnutls.so. I hope this is all it needs to run.
There is not much output. The received signed UID from the server is stored in uid.asc.
Happy hacking.
UPDATE: The server IP address was wrong. I have created a new package with the correct one.
UPDATE2: Added libgcryp.so.11 for successfull execution.
Start the program with: LD_LIBRARY_PATH=. ./uidcreator
-
compile statically, i hate to try to run some old linux proggie without source linked to some libs i dont have
-
For anyone interested in testing uid-creator I opened a thread in feedback.
The address is : http://tremulous.net/phpBB2/viewtopic.php?p=9922#9922
:wink:
-
compile statically, i hate to try to run some old linux proggie without source linked to some libs i dont have
Sorry, but I did not manage to compile it static. The problem is, I have to load GnuTLS dynamically.
But you are right, I will see what I can learn :D
UPDATE: I now (hopefully) static compile the things. Also the LD_LIBRARY_PATH is not needed anymore. The new package is on the server.
-
Here it is! The first testversion of the uidcreator. GNU/Linux only.
When you get a windows version, let us know. I want to get a version of linux but I had porblems with Ubuntu not wanting to run installed programs and I have no idea what distributions would be good for gaming.
-
I have created a (mostly) static build of the uidcreator.
It's still available at this place (http://www.mitglied.lycos.de/vsteiss/files/tremulous/uidcreator.tar.bz2)
I hope it does now run on most systems. It is a 32bit binary.
-
sure you did
error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
rasz@rasz-desktop:~/Desktop$ ldd uidcreator
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7f9a000)
libstdc++.so.5 => not found
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f78000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7f6e000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e3f000)
/lib/ld-linux.so.2 (0xb7faa000)
soo :)
Lets start from the beginning.
What are you trying to do? Generate some string individual to specific computer ? Not possible. I can virtualise and feed my specific data every time to your program. :(
The only working model is a central GUID server, and as Timbo said it will only work if GUID has some monetary value (only way to trace real life ppl is thru CC numbers)
-
sure you did
error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
rasz@rasz-desktop:~/Desktop$ ldd uidcreator
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7f9a000)
libstdc++.so.5 => not found
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f78000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7f6e000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e3f000)
/lib/ld-linux.so.2 (0xb7faa000)
Hmm, how should I build this static... please tell me if you know.
Maybe I should compile it on another system with libstdc++.so.6
I hope you all have the newest version. Updated 10 mins ago... or so... :roll:
soo :)
Lets start from the beginning.
What are you trying to do? Generate some string individual to specific computer ? Not possible. I can virtualise and feed my specific data every time to your program. :(
The only working model is a central GUID server, and as Timbo said it will only work if GUID has some monetary value (only way to trace real life ppl is thru CC numbers)
Just try to feed it with wrong information.
And tell me how it works and the time you have needed to get this far. :)
By the way: this is a central UID server. The fee is the time you need to crack it, if you want to get arround.
-
http://groups.google.com/group/gnu.gcc.help/browse_frm/thread/bfd688b59988567c
-
Thanks for information, rasz_pl.
But if I use -static-libgcc I get this error on my second system:
relocation error: ./uidcreator: symbol _dl_catch_error, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference.
I think this is the reason:
There are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared libgcc.
Sometime I will solve the problem :)
UPDATE: Just packed it with libstdc++.so.5 and libgcc_s.so.1 and created a shell script to start. The new package at the old place. (http://www.mitglied.lycos.de/vsteiss/files/tremulous/uidcreator.tar.bz2)
-
if this game became pay to play it would remove the reason why most people originally decided to play it, which was because it was free. even if it was only a small amount of money it would remove the novelty of the game, that its a cool game for a freebie and that it was not created by one of those mega big game companies.
-
How about ban by MAC address? I know that MACs are easily spoofable (e.g. in Linux it can be spoofed using ifconfig). Is it possible for trem to query the hardware for the real MAC rather than the spoofed one? Bad MACs could be distributed in a banlist.
...and we can look foward to n00bs complaining about not being able to play after buying a second hand NIC with a banned MAC.
Cheers!
-Taiyo
-
Ban system is useless in a free game. Look at Enemy Territory, it's become the most cheated game. And they have PunkBuster.
How about ban by MAC address?
Even in Windows there is many free soft/howto for change your mac address, http://www.google.fr/search?q=windows+change+mac+address&ie=UTF-8&oe=UTF-8.
Btw what about ppl using USB modem ? They don't have mac address.
-
Ban system is useless in a free game. Look at Enemy Territory, it's become the most cheated game. And they have PunkBuster.
I think you never played CS 1.5 after take down of WON servers.
And Enemy Territory is not a free game. It's free of fee but the game still is proprietary.
-
I think you never played CS 1.5 after take down of WON servers.
I don't have windows.
In fact the only way for a good banning system for a free game is IP range ban.
Btw, about uidcreator, strip/static binary is the fisrt think u need todo. I say it's useless but for learning purpose, it's good ;)
Protocol:
HELLO REQUEST
CLIENT HELLO
SERVER HELLO
CERTIFICATE
SERVER KEY EXCHANGE
CERTIFICATE REQUEST
SERVER HELLO DONE
CERTIFICATE VERIFY
CLIENT KEY EXCHANGE
FINISHED
I hope u check size for command receive from client to avoid exploit.
-
I am not using Win either, but this does not stop me playing CS 1.5 here.
I don't check the command size of the TLS commands, if you meaning this.
-
After read this http://www.tremulous.net/phpBB2/viewtopic.php?t=1052 a new idea come to me.
A master UID database server is need, I call it MUDS. Each UID is associate with a 'kill count' value.
Each new player create an UID and send it to the server. This UID is register/check on the MUDS by the server.
The server count how many kill the player got in game. After player disconnected, the server send to the MUDS the kill count.
To avoid ppl using their own server for upgrade their UID easily on MUDS, each server need to be register on MUDS as an official server. MUDS logs can be parse to avoid fast UID upgrade. Kill count is upgrade only if there is many ppl on it (like American's Army).
This system can works only if 50% max of official servers have this ban system, because players need to play on an official server without ban system to upgrade their UID 'kill count'.
This system need to be fully integrate in game to works.
UID must be based on an private/public key to avoid ppl stealing UID.
So, you can't play on an official server with ban system if you have a 'low kill count' on MUDS. And deconner/cheater/idiot can't instant reconnect on an official server.
The only bad thing is that, not all servers can have this ban system.
Btw after that, all kinds of ideas are possible. (But we talk about ban system only here)
- Create players levels based on 'kill count'.
- Server with skilled/newbie players only.
- Newbie can't deconstruct/vote.
- Skilled ppl can have some admin right.
- Stats for players.
- Register names for an UID.
- [...]
Btw PunkBuster use a similar way, a server can block players with a too young UID. But you can easily bypass this if you register many UID at the same time some days ago. It's why i use a 'kill count'.
Maybe i forget some security hole in this system. Well, it's just an idea.
Btw english isn't my native langage.
-
Make a UID system that ensure player can create multiple UID seem imposible with open-source game. You can patch the game to send faked UID, if the generator is closed-source, you only need to fake information used to generate the UID. Yes a solution could be to pay for a UID... but tremulous is free and I hope it will stay free.
But do you think that player that are banned will do all that work to fake/recreate a new UID ? I'm not sure.
I think a simple UID that can be created for free, is a the best idea. But this UID should be signed to avoid UID stealing.
From this, I see a solution against player that ruin the game is to limit action that a player can do just after registering is UID. eg can't deconstruct few minute after registering a UID.
I think the limitation time should be short, because a good player maybe playing on an other comptuer and don't have is UID key. For a banned player, if he need to wait, say, 5 or 10 min before re-deconstruct base he won't do this more than 1 or 2 times.
-
Make a UID system that ensure player can create multiple UID seem imposible with open-source game.
Well, my english is poor. Maybe it's why you don't understand me. And my idea isn't simple too.
Create a new UID don't help banned ppl. Because they need a amount of kill before reconnect to an official server with ban system.
A simple UID isn't effective. Look at Enemy Territory, you just need to delete your etkey file to reconnect to the same server (sometimes you need to change your ip too).
But do you think that player that are banned will do all that work to fake/recreate a new UID ? I'm not sure.
Yeah good point ;) I work for a security compagny, it's why i sometimes too much paranoid.
But i prefer the idea of a simple UID based on some hardware parts. So ppl can't just delete a file to create a new UID.
-
good idea that newbs cant decon!!!
that is grade A shit right there
so ya we need a ranking system like AA(even tho i hate AA)
but in this system if u get reportedly killing your own teamates u wont loose rep but a person will check u out and ban u from all MUD servers
im thinking like a 1-5 rank
rank 5 being the best and 1 being a complete noob
100 kills for rank 2, at rank 2 u get the ability to pick builder
then 400 kills for 3, at rank 3 u get the ability to decon
then 800 kills for rank 4, and the ability to start votes
then 1000 kills for rank 5, and the ability to kick players, and ure vote counts as 3 people, and ability to start votes to ban
EDIT: also what would be cool is the ability to change your human and alien characters apearence,
humans could have different clothing, differnt color skin, different face!
aliens would get like armor(but it wouldnt do anything) maybe different colors
EDIT: when someone looses there MUD acount they can creat a new one but they are back to rank 1 and they cant do shit to bug people!
-
100 kills for rank 2, at rank 2 u get the ability to pick builder
then 400 kills for 3, at rank 3 u get the ability to decon
then 800 kills for rank 4, and the ability to start votes
then 1000 kills for rank 5, and the ability to kick players, and ure vote counts as 3 people, and ability to start votes to ban
hmm...what about if there is a game with only noobs in one team? Then they couldn't build bases, or atleast decon some parts of it. And I don't think deconning newbies are a problem, atleast I didn't know how to decon when I was a noob (or maybe I still am :roll:) If rank 4 can only start votes, how can they change the map, even if they all want it.
And besides, who ever said that someone with hunreds of kills is a nice players. They can be as evil as anyone else :roll: . For example some could play with one nickname and get kills and then change to another nickname and be like little devils...
-
good point but that would leave both bases to normal while everyone goes and kills everyone to get kills and be able to get builder
-
I hope u check size for command receive from client to avoid exploit.
ascii, which size do you mean? I don't want to write exploitable programs if I can avoid this.
Would be great if you could explain it to me :)
PS: I don't like ideas like class choicing by number of kills. I would not touch the game type of Tremulous in such a drastic way, I like it how it is. Just those base destroyers border me.
-
I don't like ideas like class choicing by number of kills. I would not touch the game type of Tremulous in such a drastic way, I like it how it is. Just those base destroyers border me.
Quote!
Every player has the right to play any role, to mistake.. die.. and learn.
But base decon: they must be stopped
-
I hope u check size for command receive from client to avoid exploit.
ascii, which size do you mean? I don't want to write exploitable programs if I can avoid this.
Would be great if you could explain it to me :)
I mean buffer overflow http://en.wikipedia.org/wiki/Buffer_overflow.
The good question is: how do you store string receive from client ? If u store it in a 'char cmd[30]' and a client send a string with a len greater than 30, you got a segfault. And segfault are often exploitable to send shellcode to your server.
But i see you use c++ and maybe strings classes which are generally safe.
Btw a more secure way for you is to use a one byte protocol. You can use a 'typedef enum' for that. i mean "HELLO REQUEST"=0, "CLIENT HELLO"=1, etc. So server can reject all client command without a len of 1.
Last q3 engine exploit use this way http://www.milw0rm.com/exploits/1750.
-
I think the rank system is a good idea. There is one further thing that needs to be done--entry level servers with fewer restrictions on abilities. A training ground as it were. That way, newbies would have a chance to learn good habits before they move on to the 'big servers'.
Sure, an experienced player can start doing bad things, but they risk getting banned and losing that UID and all of the work they put into creating it. Will Griefers do all that work for *one* shot at messing up a game? Doesn't seem likely.
Of course, with the way some admins behave, the system might break down when they keep the system from applying to themselves or their friends.
-
Btw a more secure way for you is to use a one byte protocol. You can use a 'typedef enum' for that. i mean "HELLO REQUEST"=0, "CLIENT HELLO"=1, etc. So server can reject all client command without a len of 1.
I use GnuTLS so I have not to worry about the TLS protocol, so I need not to mask the commands. 8)
The good question is: how do you store string receive from client ?
If you look into the manpage of recv you see a length parameter for the buffer. If I have set this correctly there should be no possibility of a buffer overflow. arr :wink:
-
I use GnuTLS so I have not to worry about the TLS protocol, so I need not to mask the commands. 8)
I don't say that to mask commands.
If you look into the manpage of recv you see a length parameter for the buffer. If I have set this correctly there should be no possibility of a buffer overflow. arr :wink:
Depend on how you code 'client command detection'. If you do all the job in the same buffer, it's should be safe.
Btw do you use threaded server or no-blocking socket ?
Can i try crash it (only crash no shellcode) ? if yes, do you use wathdog ?
-
Depend on how you code 'client command detection'. If you do all the job in the same buffer, it's should be safe.
Btw do you use threaded server or no-blocking socket ?
Can i try crash it (only crash no shellcode) ? if yes, do you use wathdog ?
It's just a test server program without threads and without much security. If you want to crash it, it will likely do.
It just receives the data and sends the signed UID, not more not less. :)
The final server should:
- have a database of UIDs in background ;)
- check for flooding.
- use some type of exeption handling.
In the beginning I thought of thread support. But I decided it is not need, because there are only 2 transmissions per client (receive data, send signed UID). It takes less than 2 seconds and it is not necessary to handle clients in parallel. It would be overdosed... but a good training for me ;)
Edit: If you really like to test your skills, ascii, we could do some testing on Sunday :D but please wait for me ;)
-
I have finally implemented the system in revision 920: here the patch (http://mitglied.lycos.de/vsteiss/files/tremulous/tremulous-rev920-suid.patch) //edit: forgot the Makefile-patch (http://mitglied.lycos.de/vsteiss/files/tremulous/Makefile-rev920-suid.patch)
You need at least GnuTLS 1.4.0 for this to work, and the static libs (http://mitglied.lycos.de/vsteiss/files/tremulous/tremulous-rev920-suid-dedicated.zip) to build the dedicated server.
I also have started the uidserver again so you can create a signed UID for your system using the uidcreator (http://mitglied.lycos.de/vsteiss/files/tremulous/uidcreator.tar.bz2).
As I was thinking about this solution I found out that it is an insecure solution: A manipulated server can steal the UID and the signature.
To solve the issue a central server can be used to verify the clients identity. The Tremulous server then only needs the UID but not the signature.
-
if you are thiking about ranking, then, no.
I like how you don't have to register your account.
And I really hated the AA system where you are rank 20 and others are rank 100 and all those crap.
I was sad when I was rank 10 and everyone else were rank 20
they called me noob and stuff :(
but later i got to rank 21!
and I stopped playing
and I tried to play again
but I had to restart
so I said "F**K IT"
wait... what are we talking about?
-
if you are thiking about ranking, then, no.
I like how you don't have to register your account.
And I really hated the AA system where you are rank 20 and others are rank 100 and all those crap.
I was sad when I was rank 10 and everyone else were rank 20
they called me noob and stuff :(
but later i got to rank 21!
and I stopped playing
and I tried to play again
but I had to restart
so I said "F**K IT"
wait... what are we talking about?
lol you're funny. It's a system to identify a player based on his system information. Maybe you should read the whole post frist :wink:
-
The best way to actually ban someone, is not to have it ban based off of crap that can be recreated, but to be banned based off of Volume Id and MachID. Volume ID is the ID of your harddrive, and although it can be changed, with the backup of MachID, it is practically fail safe. The only way for the person to bypass the ban, is to essentially get a new Nic Card, and change there Volume ID. Which is a lot of trouble...and if they do it again, ban them again...eventually they will give up. It becomes too costly.
this sounds like the best idea out of what ive read...but i wouldnt like it as i wouldnt be able to evade my bans :(
-
The best way to actually ban someone, is not to have it ban based off of crap that can be recreated, but to be banned based off of Volume Id and MachID. Volume ID is the ID of your harddrive, and although it can be changed, with the backup of MachID, it is practically fail safe. The only way for the person to bypass the ban, is to essentially get a new Nic Card, and change there Volume ID. Which is a lot of trouble...and if they do it again, ban them again...eventually they will give up. It becomes too costly.
this sounds like the best idea out of what ive read...but i wouldnt like it as i wouldnt be able to evade my bans :(
No, this is a stupid idea. Who sends the server the Volume ID or the easily changed MAC address? The client software. The one who can be easily changed to send a random Volume ID and MAC address by placing a few calls to rand in carefuly chosen and easy to find locations in the source code.
This won't work.
-
If someone is testing the uidcreator it would be nice if he/she would send me the UID as P.M. so I can check if it really works.
Unfortunately it's only available for GNU/Linux (maybe it runs on other *nix-Derivates too) at the moment.
-
Way to necro.
-
Way to necro.
way to make three words of awesome cliche.
-
way to not notice until 2938 posts have been made since the necro. and stof why cant we just make it harder to find in the source code? we can make a bunch of ascii drawrings of tyrants around it and then no1 could touch it
-
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.
-
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.
-
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:
-
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. :)
-
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 :P
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.
-
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.
-
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 (https://bugzilla.icculus.org/show_bug.cgi?id=3019#c13). 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.
-
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 (http://mitglied.lycos.de/vsteiss/files/tremulous/uid_public.key) so you may test the Tremulous server with signed UID patch if you desire.
-
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.
-
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.
-
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.
-
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 ;)
-
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.
-
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.
-
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?
-
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
-
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? :D
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.
-
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? :D
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.
-
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 (http://www.gnu.org/software/gnutls/manual/html_node/The-X_002e509-trust-model.html#The-X_002e509-trust-model).
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.
-
It might be a good idea to start with Wikipedia (the source of all useful knowledge :) )
- Web of Trust (http://en.wikipedia.org/wiki/Web_of_Trust)
- Public Key Infrastructure (http://en.wikipedia.org/wiki/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).
-
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)?
-
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.