Author Topic: GUID registration system  (Read 31324 times)

Hxaltai

  • Posts: 7
  • Turrets: +0/-0
    • http://trem-servers.com/
GUID registration system
« Reply #60 on: September 17, 2007, 10:14:53 pm »
Quote from: "Caveman"
And gpg / pgp is still useless as this does something quite opposite to what we need. It only proves that someone is who they say they are.
ID'ing for admin-lvl on servers is a done thing, see server-unique-guids for that we need no gpg/pgp and spoofing is not really possible with that guid :)

Server unique GUIDs are just an ugly hack and have a flaw. They don't identify people between servers, which would be useful when you're running multiple servers yourself (you could share the player database) or to discourage known name spoofers (where names aren't protected). I'm all for an RSA GUID system.
EZ|Hxal|Lunatic of [T] servers

Caveman

  • Guest
GUID registration system
« Reply #61 on: September 17, 2007, 11:48:22 pm »
Quote from: "Hxaltai"

Server unique GUIDs are just an ugly hack and have a flaw. They don't identify people between servers, which would be useful when you're running multiple servers yourself (you could share the player database) or to discourage known name spoofers (where names aren't protected). I'm all for an RSA GUID system.



Just for the record, we are maintaining several servers on different IPs and have yet to encounter the 'Problem' where we had need for that.

If you'd actually followed this thread then you'd know that what you are for is also a failure in itself as the encryption of a guid does not matter if someone does not want to be ID'ed.

player1

  • Posts: 3062
  • Turrets: +527/-401
    • My Avatar! (if they were enabled) [by mietz]
maybe it should be your sig, dude...
« Reply #62 on: September 17, 2007, 11:53:21 pm »
just to save Caveman from having to constantly repeat himself:

YOU CAN'T ID PLAYERS WHO DON'T WANT TO BE ID'd!!!

outlawing guns means only outlaws have guns

Hxaltai

  • Posts: 7
  • Turrets: +0/-0
    • http://trem-servers.com/
GUID registration system
« Reply #63 on: September 18, 2007, 12:47:26 am »
Quote from: "Caveman"
If you'd actually followed this thread then you'd know that what you are for is also a failure in itself as the encryption of a guid does not matter if someone does not want to be ID'ed.
If you'd actually read my post then you'd notice no implication of such a possibility. What I was for is a GlobalUID system for those players that want to be positively identified, in place of the Server-Local Unique IDentifier.

Quote from: "Caveman"
Just for the record, we are maintaining several servers on different IPs and have yet to encounter the 'Problem' where we had need for that.
There's never a problem if you're working around it actively.
EZ|Hxal|Lunatic of [T] servers

Caveman

  • Guest
GUID registration system
« Reply #64 on: September 18, 2007, 01:25:04 am »
Dude, get a clue.
As soon as there is (again) a guid that is transmitted to a server it is compromised.
And no matter if you only send a hash or the guid itself.

If you find a way to stop malicious server admins to 'steal' the hash / guid and to mod an Open Source client, your idea might have some worth.

Until then it's just half baked BS that is not needed and more work than it's worth.

Hxaltai

  • Posts: 7
  • Turrets: +0/-0
    • http://trem-servers.com/
GUID registration system
« Reply #65 on: September 18, 2007, 01:40:42 am »
Quote from: "Caveman"
Dude, get a clue.
As soon as there is (again) a guid that is transmitted to a server it is compromised.
And no matter if you only send a hash or the guid itself.
If you find a way to stop malicious server admins to 'steal' the hash / guid and to mod an Open Source client, your idea might have some worth.
Until then it's just half baked BS that is not needed and more work than it's worth.

I see you have no idea how an RSA challenge-response system would work. The private key or hash thereof is never sent to the server. There is absolutely no way to steal the private key short of actually hacking the client.

Background:
RSA is an asymmetric key system, where you compute a pair of keys, and you can encrypt stuff with one key that is decryptable with the other.

It works like this:
- client sends pubkey to the server, that becomes the users GUID
- server sends a randomly generated challenge string to the client
- client encrypts the challenge with privkey and sends the response to the server
- server decrypts the response with pubkey and checks if it's identical to the challenge string, doesn't let the player in if they differ

The privkey is never transmitted, there is no way to infer privkey from pubkey in reasonable time, or compute a new privkey that works with pubkey. You can't just spoof the pubkey because no server will let you in. You can't spoof the privkey because you don't have it.

This is the simplest scenario, a scenario hardened using common cryptographic practices would work very similarly though.
EZ|Hxal|Lunatic of [T] servers

kevlarman

  • Posts: 2737
  • Turrets: +291/-295
GUID registration system
« Reply #66 on: September 18, 2007, 03:38:28 am »
Quote from: "#tremulous-dev@irc.freenode.net"
19:14  kevlarman> timbo, would you be against adding something a bit more secure
 than cl_guid?
19:14  kevlarman> (assuming someone else did the work of course)
19:15 @Timbo> is it really that insecure?
19:16  kevlarman> well with cl_guidserveruniq it isn't
19:16  kevlarman> but then you can't even have 2 servers sharing admins
19:17  kevlarman> we have 2 servers running on the same box and we have to give
everyone admin by hand
19:17 @Timbo> cl_guidserveruniq should be the default imo
19:18  kevlarman> probably yeah
19:18 @Timbo> by which i mean you can't turn it odd
19:18 @Timbo> off
19:18  kevlarman> that might be excessive
19:19  kevlarman> i was thinking about grabbing an rsa implementation from opens
sh or something
19:19 @Timbo> i'm definitely against that
19:19  kevlarman> and adding a client command/game command to avoid breaking any
thing
19:19  kevlarman> any particular reason?
19:19 @Timbo> there is a limit to how important admin on a computer game server
is :)
19:19 @Timbo> RSA is totally overkill

looks like we won't be getting anything like digital certificates to identify players :(
Quote from: Asvarox link=topic=8622.msg169333#msg169333
Ok let's plan it out. Asva, you are nub, go sit on rets, I will build, you two go feed like hell, you go pwn their asses, and everyone else camp in the hallway, roger?
the dretch bites.
-----
|..d| #
|.@.-##
-----

player1

  • Posts: 3062
  • Turrets: +527/-401
    • My Avatar! (if they were enabled) [by mietz]
thx
« Reply #67 on: September 18, 2007, 04:00:11 am »
ty

FooBar

  • Posts: 94
  • Turrets: +9/-1
    • http://avalanche.server.googlepages.com
GUID registration system
« Reply #68 on: September 18, 2007, 07:25:11 am »
Quote from: "Timbo"
there is a limit to how important admin on a computer game server is :)

Ha!  Yes, that's exactly why I haven't tried an implementation myself.  Well, that and my thesis.  Such as it is.

Caveman, you never really understood the point of my post.  I understand that you cannot ID players who don't want to be ID'ed.  My post was about providing unique, global, non-spoofable, totally secure ID for players who DO want to be IDed.  And as Hxaltai stated, a private-public key pair would work extremely well for that.  A side effect would be that every server could also have such a unique ID.

But as Timbo says, it's probably not important enough to be worth the trouble.  :D

Caveman

  • Guest
GUID registration system
« Reply #69 on: September 18, 2007, 09:48:31 am »
And once again I need to state that it's only those that do not want do be ID'ed are the problem. For the rest we do already have a way that is 99% secure.

kevlarman

  • Posts: 2737
  • Turrets: +291/-295
GUID registration system
« Reply #70 on: September 18, 2007, 05:14:27 pm »
Quote from: "Caveman"
And once again I need to state that it's only those that do not want do be ID'ed are the problem. For the rest we do already have a way that is 99% secure.
it's still a pain to lose your entire admin list when your server moves....
Quote from: Asvarox link=topic=8622.msg169333#msg169333
Ok let's plan it out. Asva, you are nub, go sit on rets, I will build, you two go feed like hell, you go pwn their asses, and everyone else camp in the hallway, roger?
the dretch bites.
-----
|..d| #
|.@.-##
-----

benmachine

  • Posts: 915
  • Turrets: +99/-76
    • ben's machinery
GUID registration system
« Reply #71 on: September 18, 2007, 06:44:06 pm »
Even if Timbo doesn't want it in mainline Tremulous, I think we should see what can be done with GPG for several reasons:
1. it's much easier to say 'yes, let's include that' than 'yes, let's include what that might eventually be'
2. the rate of uptake might persuade him that lots of people like it and use it, and it would therefore be a valuable addition to the codebase
3. most people aren't using "official" code on their servers and clients anyway, if we manage to contain a modification to client binary/game.qvm (like tjw did with g_admin), then the transition should be nice and smooth and before you know it, it will be everywhere.
benmachine

sleekslacker

  • Posts: 407
  • Turrets: +10/-35
GUID registration system
« Reply #72 on: September 19, 2007, 11:04:05 am »
Honestly, I don't see what's Timbo's reason for not accepting a number of things in the code ( libvorbis for example ). Go on and see what you can do with GPG and let's see if the public will be smart enough to use it. Thanks to GPL, the worst it can bring us is a fork of the project.
y last name is Jones, the family motto is "Jones' never give up!"

Currently ignoring all of your spams.

next_ghost

  • Posts: 892
  • Turrets: +3/-6
GUID registration system
« Reply #73 on: September 19, 2007, 12:49:56 pm »
Erm, you do realize that however the ID system works, the server part must finish in much less than 50ms? I'm not really sure GPG can do that, especially when you have multiple keys.
If my answer to your problem doesn't seem helpful, it means I won't help you until you show some effort to fix your problem yourself!
1.2.0 release's been delayed for 5:48:00 already because of stupid questions.

Caveman

  • Guest
GUID registration system
« Reply #74 on: September 19, 2007, 01:09:07 pm »
Why must it be done in 50ms?
To get pgp/gpg included you'd have to rewrite server and client code anyhows, so 'just' remove this timelimit... (Yes I know that WILL open Pandora's Box)

next_ghost

  • Posts: 892
  • Turrets: +3/-6
GUID registration system
« Reply #75 on: September 19, 2007, 01:44:09 pm »
Quote from: "Caveman"
Why must it be done in 50ms?
To get pgp/gpg included you'd have to rewrite server and client code anyhows, so 'just' remove this timelimit... (Yes I know that WILL open Pandora's Box)


50ms = 20 server frames per second. You can't remove that limit without freezing the server for a few frames (or worse, seconds) and lagging everyone. It could be possible to use separate thread for authentication though. But I'm sure nobody would want to debug that.
If my answer to your problem doesn't seem helpful, it means I won't help you until you show some effort to fix your problem yourself!
1.2.0 release's been delayed for 5:48:00 already because of stupid questions.

Caveman

  • Guest
GUID registration system
« Reply #76 on: September 19, 2007, 02:04:40 pm »
Quote from: "next_ghost"

50ms = 20 server frames per second. You can't remove that limit without freezing the server for a few frames (or worse, seconds) and lagging everyone...


I still don't get your argument, as I have no clue of the code, you might want to take me slowly through this argument.

I also don't understand your explaination of how 50ms can be equal to 20sfps.

next_ghost

  • Posts: 892
  • Turrets: +3/-6
GUID registration system
« Reply #77 on: September 19, 2007, 04:06:46 pm »
Quote from: "Caveman"
I still don't get your argument, as I have no clue of the code, you might want to take me slowly through this argument.

I also don't understand your explaination of how 50ms can be equal to 20sfps.


The server runs in a single thread in one huge loop. In general, one loop step looks like this: read incoming packets and parse client commands, calculate new gamestate, send the gamestate to clients, rinse & repeat. Right now, the authentication through GUID takes place during packet reading and client command parsing.

The standard server setting is 20fps and when a frame is finished, the server will sleep until it's time to calculate the next frame. That means that every frame takes 50ms (because 50ms * 20 = 1000ms = 1s).

If you don't finish the frame in less than 50ms, the server won't start sending gamestate updates in time and the game will lag.
If my answer to your problem doesn't seem helpful, it means I won't help you until you show some effort to fix your problem yourself!
1.2.0 release's been delayed for 5:48:00 already because of stupid questions.

Hxaltai

  • Posts: 7
  • Turrets: +0/-0
    • http://trem-servers.com/
GUID registration system
« Reply #78 on: September 19, 2007, 04:43:06 pm »
Quote from: "next_ghost"
...

I see your point. I made a benchmark with python's M2Crypto based on OpenSSL and it takes about 37ms to encrypt or decrypt using RSA-2048bit with C2D at 2.13GHz and 51ms at 1.6GHz. While it is quite a long time I doubt it would present itself as a problem, because cryptographic operations need to be done only at a new connection setup. I'm not sure whether the connection is reinitialized across map reloads, but even if it was the case, identity could be somehow cached.
Nevertheless if we were concerned with a possible DoS attack exploiting the overhead of cryptography we can always throw it into a separate thread and have the client wait for a connection a moment longer.
EZ|Hxal|Lunatic of [T] servers

FooBar

  • Posts: 94
  • Turrets: +9/-1
    • http://avalanche.server.googlepages.com
GUID registration system
« Reply #79 on: September 19, 2007, 08:17:44 pm »
Yes, I wasn't really considering that EVERYTHING would be encrypted or authenticated... My only interest in GPG was that it would provide a GUID (the public key) that could not possibly be spoofed or stolen. I envisioned that at connection time, and at the start of every map, there would be a little interaction between server and client.  In this interaction:[list=1]
  • The client would prove it was the true owner of its public key,
  • The server would prove that it was the true owner of its public key; and
  • All game traffic would proceed as usual (without continual verification), just using the public key as the GUID.[/list:o]As far as I know, a public key could be trivially dropped in to replace the current data in the GUID.  The only difference is, I think a public key contains more bytes of data, which I guess would mean a slightly larger packet?

    Then, for example, SST would know that I was the same FooBar who signed on yesterday.  And I would know that Fragify (New York) was a totally different server from Fragify (Virginia), and not just the old server in a new location.

    The only reason to (a) continually authenticate, or even (b) encrypt all game traffic, would be if you wanted to [list=a]
  • Prevent some kind of insane man-in-the-middle spoofing; or
  • Keep any hypothetical internet eavesdroppers from learning you just got pwned.[/list:o]Unless we want to introduce secure online shopping in Tremulous. ;)

    I thought that mandatory GUIDs (always-on-GUID by default), combined with public-key-based GUIDs, would make it easy, for example, to deal with multiple players from the same IP address, and various other admin situations that can be a little tricky.

    And of course, with a global GUID registration system GPG would probably be necessary, in the long run, to prevent rampant spoofing from making the system worthless.  So that brings the whole conversation back on-topic.  ;)

    But I'm not really interesting writing it,  since as Timbo says, it's a lot of trouble and it may not really be worth it.  Oh, someday if I'm really bored I may take a stab at it, but not right at the moment.  :D  I just wanted to know if anyone had seriously talked about it.  And now we have!

/dev/humancontroller

  • Posts: 1033
  • Turrets: +1002/-383
GUID registration system
« Reply #80 on: September 29, 2007, 09:18:52 am »
Quote from: "kevlarman"
qvms don't get linked against the crt
Timbo just added isalnum() to the Q3 code.
http://svn.icculus.org/quake3/trunk/code/qcommon/q_shared.h?r1=1168&r2=1185&p1=trunk/code/qcommon/q_shared.h&p2=trunk/code/qcommon/q_shared.h

Caveman

  • Guest
GUID registration system
« Reply #81 on: September 29, 2007, 09:58:54 am »
is there anything older than the news from last week?

Foobicam

  • Posts: 72
  • Turrets: +0/-0
GUID registration system
« Reply #82 on: September 29, 2007, 06:04:03 pm »
Quote from: "FooBar"
Yes, I wasn't really considering that EVERYTHING would be encrypted or authenticated... My only interest in GPG was that it would provide a GUID (the public key) that could not possibly be spoofed or stolen.

The standard way to protect EVERYTHING (as in IPSec or TLS) is to use public key agreement protocol (10's of milliseconds) to establish a session key, and then use the session key to authenticate traffic using HMAC (sub-milliseconds).  Not that there is a crying need to authenticate normal player traffic, but all privileged (admin) actions would benefit from session authentication.

Caveman makes lots of good points, but this:
A failsafe way to ID a player, one that can not be spoofed.
is not one of them.  Public key authentication is a failsafe way to ID a player that cannot be spoofed, unless you can hack that player's computer to steal his private key. USB tokens or smartcards address that problem.  Because Tremulous doesn't have much of intrinsic value (admin privileges are fun, but don't hit you in the pockebook like online banking or shopping) there is not a huge incentive to spoof an existing ID.  The problem addressed by invites, whitelists, eBay-like reputations, pay-per-ID, etc, is the ability to mint an unlimited number of new IDs at very low cost.  As long as minting IDs is easy, there is little incentive for a griefer to spoof someone else's ID.  If Tremulous had a mechanism for adding value to IDs, griefers would have more incentive to steal an existing ID rather than minting a new one, and authentication would then be needed.

So what is an appropriate way to add value to Tremulous IDs?  Reputation, in my opinion.  This would involve:

* Each server operates a reputation system (like Dretch*Storm's experience points - XP) according to its own formula.  Griefing would be penalized by reducing XP for successful votekicks, admin kicks, and bans of various duration.  The server operator could link in-game reputations with forum reputations (post counts or member ranks) to make it more difficult to quickly mint new in-game IDs.  A server could require pay for play (although I certainly wouldn't pay simply for the privilege of avoiding griefers and I doubt such a server would succeed).  Much better would be inferred payment: require registration through an institutional email account (isp-provided, .edu or corporate, but not hotmail/gmail/yahoo).  A griefer might have access to a few such addresses (Verizon permits 8 email addresses per account) but not an unlimited supply.

* Each server publishes its reputations using a standard (to-be-defined) interface which any other server could query.  There is no need for a centralized "ban" server, the existing master server allows a server to find all other servers that send a heartbeat.  The reputation query would contain a GUID; the response would contain the public key used to authenticate that GUID and the reputation info.

* Each server would collect reputations from every other server it cared to check (valuing the opinions of some servers more than others).  It would then make a decision to admit or deny a player using its own criteria.

A crucial point of this scheme is federation: there is no central authority for making ban decisions.  Instead there is an information sharing federation in which every server is sovereign: it publishes what it chooses to publish, and makes whatever decisions it wishes based on information published by others.

A second crucial point is that because new GUIDs can be minted and because, if per-server GUIDs are used, a player can choose which GUIDs to disclose and thus which servers' reputation info can be linked to the player, THERE IS NO VALUE in attempting to rely on negative reputations as a reliable way of detecting griefers.  Caveman is absolutely correct on this point: a GUID does not ID a player unless he wants it.

So why bother?

Because if there are a few well-admined servers that limit GUID minting somehow (e.g. by requiring registration from a paid email address) and choose to share their users' XP info, then they would be able to leverage each others efforts.   Perhaps the federation would grow in popularity, or perhaps good (well-intentioned, whether skilled or noob) players would migrate to more griefer-friendly servers.  Hard to say without trying.
url=http://img265.imageshack.us/img265/472/foobvn0.jpg]Image Sig[/url] removed.

tuple

  • Posts: 833
  • Turrets: +97/-80
Re: GUID registration system
« Reply #83 on: November 26, 2007, 09:45:08 pm »
The problem with user identification is that it really only works with users who WANT to be identified.  Tracking a user who does not want to be identified is not easy, and is impossible for a game server.

The problem with this federation reminds me of an old mad magazine joke.

A man walks into an office and up to the front desk.  "I'd like to attend trucking school." He says.
"Are you a member of the truckers union?" The person behind the desk asks.
"No"
"You have to be a member of the truckers union to attend trucking school."
"ok, can I join the truckers union?"  The man asks.
"Are you a trucker?"  The desk clerk asks.
"umm, no"
"You have to be a trucker to join the truckers union."