Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000295Zandronum[All Projects] Suggestionpublic2011-02-15 22:202014-06-14 03:25
ReporterAlexMax 
Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000295: Login server proposal.
DescriptionAround the time of our open source discussion a day or two ago in #skullrant, the idea was floated that Skulltag might want to have a "login server" for skulltag.

---
<@Torr_Samaho> I think that increased danger of cheating is a problem that has to be factored into the decision. I agree that a login system or something like this could take care of this, but then also someone needs to implement such a system. If someone finds a volunteer for this, this could help to tip the scales ;).
---

My idea of a authentication server fills the following requirements:

1. Verifies someone is who they say they are (a deterrent against aliasing, also a deterrent against cheating since someone's reputation is at stake). Also could allow for persistence on a server through the use of ACS.
2. Open source and decentralized. "Bus-proofing" Skulltag as it were.
3. Not required. People should be able to play anonymously, but they should be distinct from logged in users and thus be put under more scrutiny. Servers could perhaps disallow anonymous play.
4. Clients should not be trusted at all. Game servers should be trusted insofar as if they are caught lying their reputation is ruined, but should never handle the client's password directly. Login servers are trusted.
Steps To ReproduceInstead of describing the login server itself, I think it would be better to describe the lifecycle of an authenticated connection:

1. I enter at the skulltag console (or at the command line as a command line param):
authconnect funcrusherplus.net:10668 alexmax@authserver.com mypassword
2. Skulltag sends the auth server a packet consisting of (username, password, server IP/port, random secret). After that, it connects to the game server like normal...except it also sends the game server the random secret and the authserver domain.
3. The auth server (skulltag.com) gets the username and password and tries it out.
4. If the username and password match up, the auth server sends the game server a packet consisting of (ip, random secret).
5. The game server gets the packet from the auth server. If the client's auth server, random secret and ip match up, the user is considered authenticated, and the game server sends the auth server the random secret back with an "OK" message. Once this happens the login server shows on a webpage somewhere "User alexmax was spotted on <servername>".
6. From then on, clients and the server can use 'playerinfo' to see what username and login server each player is using.
Additional InformationPotential attacks:
- Bad auth servers stealing passwords.
- Bad clients stealing passwords.
- Bad servers lying about user authentication. Nothing we can do about this, especially not if the game goes open source. Servers will get a reputation for being reliable and this will only be an issue on unknown servers.
- Bad clients lying about their login status to the auth server in order to spam inaccurate or misleading "This user was spotted at <server>" messages. This would require coordination between a malicious client and server, as you must have access to a valid account and access to something that can send back the "OK" message. Abuse of the login server like this could easily be blocked.

For my part, I could see about coming up with a proof-of-concept authentication server. Would the usage of gzipped-JSON-RPC be too onerous for Skulltag clients and servers?
Attached Filespng file icon login_success.png [^] (161,206 bytes) 2014-04-16 00:40

- Relationships
related to 0001176new Account system development/discussion 

-  Notes
User avatar (0001110)
AlexMax (developer)
2011-02-21 00:22
edited on: 2011-02-21 00:27

 Is this bug a blocker on bug 291?

Also, I've gone ahead and converted the Skulltag huffman encoder/decoder to Python. I figure that if I'm talking to Skulltag, I'm going to want to talk to the server directly in a format that it already understands. I'll see about getting you a communications protocol soonish and hopefully if we come to an agreement about that I can code the login server to spec.
User avatar (0001186)
Torr Samaho (administrator)
2011-03-26 15:38
edited on: 2011-03-26 15:41

 > Is this bug a blocker on bug 291?

No, but having this would make the decision to go open source easier.
User avatar (0001192)
AlexMax (developer)
2011-03-27 05:31
edited on: 2011-03-27 05:39

 > No, but having this would make the decision to go open source easier.

At the risk of getting off topic, I've got two questions:

1. How does the existence of a login server make you feel easier about going open source? Doubly so for one of my suggested design, which would allow people to run their own login servers and be completely optional.
2. What other factors are at play for bug 291? What other factors make the decision easier or harder?

I ask because although I like the idea and could go ahead and get started on it, the idea of a login server did not seem to go across as well in the thread. I personally am only interested in it for persistence sake (perhaps by hooking into it via ACS), and as a tool to manage players on servers (a more convenient way of handling private CTF, for instance), and now that I've had some time to think it over, I don't particularly think it will have a significant impact on cheating regardless of the implementation (mine or a far more draconian one).
User avatar (0001193)
tm512 (reporter)
2011-03-27 05:38

 I am not in favor of having an auth server. You say that it could deter cheating because reputations would be at stake, yet anyone that cares about having a respectable reputation is unlikely to go to the route of cheating. Also, is an IP address not enough of an identifier? If anyone gets caught cheating you can count on it that their identity will be uncovered in time.

Also, this could put anyone who chooses to play anonymously under unfair scrutiny from the rest of the community, perhaps giving people the preconception that an anonymous user is more likely to cheat (look up "preconfirmed bias" to know what I am hinting at).

Furthermore, this just adds something else that has the possibility of being exploited, and time spent maintaining the auth servers could be better spent elsewhere.
User avatar (0001226)
Torr Samaho (administrator)
2011-03-30 01:58

 > 1. How does the existence of a login server make you feel easier about going open source? Doubly so for one of my suggested design, which would allow people to run their own login servers and be completely optional.

I see it as a potential way to hedge out caught cheaters. Of course only on trusted servers that disallow anonymous players. I haven't thought about how this would work in detail yet though.

> 2. What other factors are at play for bug 291? What other factors make the decision easier or harder?

It's better to discus this in 0000291. Just to name one thing: Only relatively few people (less than hundred) voted in the forum poll so far. Considering that there are usually more than hundred players playing online at once, only a fraction of the player base voiced their opinion yet.

> Also, is an IP address not enough of an identifier?

No. On the one hand, it's easy to evade an IP ban and on the other hand, innocents often get caught in IP range bans.
User avatar (0001236)
AlexMax (developer)
2011-03-30 21:29
edited on: 2011-03-30 21:30

 > I see it as a potential way to hedge out caught cheaters. Of course only on trusted servers that disallow anonymous players. I haven't thought about how this would work in detail yet though.

What is preventing a cheater from registering a one-time use disposable account just for cheating?

If I'm Mr. Cheater and I want to play on a Skulltag server that requires logging in (no anonymous play), I'll turn on my proxy, register an account and have the confirmation e-mail sent to mailinator so I don't need a fake gmail account. With the fake username and password I'll join a server, turn on my aimbot and spam until i'm banned. The login server did nothing in this case.

One _possible_ use case, however, is to keep track of "known players gone bad". If we log IP's of people who are joining servers and logging in, this means that we can cross-reference "questionable" IP's against it, similar to how we operate now when Cyber or whoever asks me for the IP of such-and-such suspected cheater. In effect, the login server would act as one giant global logfile for connects/disconnects for authenticated users.

However, this would only help us catch players who are too dumb to proxy while they're cheating/griefing, and its effectiveness does not rely on logging in being mandatory for all players (including anonymous ones), since we can always grab the "questionable" IP out of the server logfile like we do now instead of it being in the login server database by default. Also, this usage of the login server as a 'global logfile' would imply there being one authoritative login server, and I would prefer to keep the possibility of multiple login servers there to ensure that no one person or group of people holds the keys to the Skulltag kingdom and also to allow for customization. Cutmanmike could run his own login server for MM8BDM servers with a special Megaman theme, for example, and I could run my own FUNCRUSHER+ login server to help manage who can and can't join Private CTF.
User avatar (0001237)
Torr Samaho (administrator)
2011-03-30 23:50

 > What is preventing a cheater from registering a one-time use disposable account just for cheating?

You would need to have a moderated registration process.

Furthermore, if you combine IP range bans on the registration with moderated registration, you would also have a way to whitelist someone in an IP independent manner.

This are just some basic ideas though.
User avatar (0001239)
AlexMax (developer)
2011-03-31 12:15
edited on: 2011-03-31 12:53

 > You would need to have a moderated registration process.

If mandatory registration to play on a server is a hassle, mandatory moderated registration is ten times this because there is a human delay in registration. Not even ZDaemon does this, as you can join a server anonymously from IDE.

What is a moderator checking for anyway? If I am Mr. Cheater and I use a proxy, a new fake name and a one time use email address, how is human verification going to catch me in a way that automatic checks could not?

> Furthermore, if you combine IP range bans on the registration with moderated registration, you would also have a way to whitelist someone in an IP independent manner.

I _do_ like this idea, though. However, it does go against the distributed nature of my proposed login server, as it requires a server to 'trust' a login server not to send them login credentials they don't trust. In addition, how do we tell the difference between a careless cheater who forgot to turn on their proxy and an innocent player who just so happens to come from a banned IP range?

To be clear, I think that a login server is a good idea. However, I think that there is a balance to be struck between convenience to the end user, usefulness to the server owner and usefulness to the login server owner; and I think that using the login server as a cheater filter would compromise too much in terms of end user convenience and wouldn't be effective in preventing cheaters from playing anyway.
User avatar (0001243)
AlexMax (developer)
2011-03-31 22:35
edited on: 2011-03-31 22:36

 I think I have thought of an acceptable compromise. These are server variables that are set on the skulltag server.

auth_onlyauthed, which disallows players who are not authenticated from playing.
auth_trustedservers, which contains a comma-delimited list of authentication servers that the server "trusts". Any authentication that comes from one of those servers is considered good, any authentication that comes from any other server is treated as unauthenticated for the purposes of "auth_onlyauthed". If onlyauthed is true, connections from untrusted auth servers are rejected. If onlyauthed is false, connections from untrusted auth servers are accepted and displayed in playerinfo, but are marked somehow to indicate that they're untrusted.

It would also be nice if skulltag's banlist, whitelist and adminlist could accept auth names (in the format <username>@<authserver domain>) in addition to ip addresses.
User avatar (0001245)
Torr Samaho (administrator)
2011-04-01 00:33

 Sounds good to me.
User avatar (0001304)
AlexMax (developer)
2011-04-07 02:57

 Did some work on the nitty gritty communication protocol for the login server tentatively named Charon, named for the greek mythical ferryman of hades:

'http://tinyurl.com/3kouuh6 [^]'

Here is a more precise method of how the login happens:

1. User enters 'authconnect <server>:<port> <username>@<loginserver> <password>' at the console and presses enter.
1. Client sends Login Server (henceforth called Charon to differentiate itself from the skulltag game server) the packet shown in Table 2.
2. Charon can send the client any one of the error packets in Table 6. If this happens, the client (Skulltag) should display an error message in the console to this effect and halt the connection attempt.
3. If Charon does not find anything wrong with the client which necessitates sending an error packet, it will send the client back a response as shown in Table 3, which contains a random number "secret". Charon stores the secret serverside in order to identify the login attempt uniquely.
4. The client, upon getting the packet with the secret, sends the packet as shown in Table 4 to Charon. It resends the "secret" (to ensure that it is considered the same login attempt), the server ip and port that the client is attempting to connect to (so Charon knows where to send the results of the authentication attempt) and the username and password.
4a. I am far more concerned with a potential database compromise on the server that hosts Charon itself than over-the-wire security of the password from the client to Charon. The method that RCON uses to transmit its passwords in an encrypted fashion (send a salt, client hashes + salt and sends it back) is infeasible since it relies on the RCON password being in plaintext on the server side. Thoughts on this subject are welcome, but I am investigating the possibility of the password being in cleartext in terms of the protocol but using SSL for over-the-wire security.
5. The client, immediately after sending the authentication packet to Charon, connects to the server like normal. However, the client provides the server with the hostname of the Charon server it is authenticating with, as well as the secret that it was given.
5a. If the server has the setting 'auth_enabled' set to false, the server ignores the authentication data that the client sends and the client joins normally.
5b. If the server has 'auth_enabled' and 'auth_onlytrusted' set to true and the hostname that the client sent as its login server is not in the list of 'auth_trustedservers', the client is immediately disconnected from the server.
5c. If the server has 'auth_enabled' and 'auth_onlytrusted' set to true and the hostname that the client sent as its login server is in the list of 'auth_trustedservers', the client can join, but the client is muted and force-spectated and regarded as an anonymous player. If the server waits 'auth_timeout' seconds (default is 30) and the appropriate Charon server does not authenticate the user, the client is disconnected. If 'auth_timeout' is set to 0 in this case, the mute and force-spectated client can stay indefinitely.
5d. If the server has 'auth_enabled' set to true but 'auth_onlytrusted' set to false, the client can join normally and is regarded as an anonymous player.
6. Charon checks the authentication information that the client sent it back in step 4. It then sends a packet listed in Table 5 to the _SERVER_ (not the client) with the secret and result of the authentication.
6. If the server has 'auth_enabled' set to false, any authentication packets it gets are ignored. Otherwise, the server checks the packet that it got from Charon server. If the hostname of the Charon server and the secret that the Charon server sent it match any of the connected clients, we go to step 7. Otherwise, nothing happens.
7a. If the server finds out that the user did not pass authentication, we notify the matched user that their authentication has failed. That user can resubmit authentication without leaving the server by using 'auth <username>@<loginserver> <password>' at the console. However, they _could_ get kicked by 'auth_timeout' in the meantime.
7b. If the server finds out that the user passed authentication, that user is no longer considered anonymous and is considered 'authenticated' with their given username and login server combination. However, if the charon server the user is using is not listed in 'auth_trustedservers', they are still considered authenticated, but untrusted.

A users authentication status is listed in 'playerinfo' and is visible to both clients and servers. For servers, their authentication information comes after their name but before their IP address. Authentication information has the format of "<username>@<loginserver>" for authenticated users, "<username>@<loginserver> (U)" for untrusted authenticated users (auth_onlytrusted is false but auth_trustedservers has entries in it and the given login server does not match the entry) and "Anonymous" for anonymous users.

Anything you guys feel is missing?
User avatar (0001306)
AlexMax (developer)
2011-04-07 11:49
edited on: 2011-04-07 11:55

 I missed some stuff:

1. The protocol is huffman-coded and little-endian, just like all other Skulltag Traffic. At this point I have a working reimplementation of the huffman encoder/decoder in python, all it is missing at this point is a way to send the unencoded string in cases that it is smaller vs the encoded string, and that is a trivial addition.
2. Charon's default port is 11666. 'authconnect' and 'auth' can also take a custom port number after the <username>@<loginserver> bit, like so: <username>@<loginserver>:<port>. Custom charon ports are _only_ important for the initial client -> charon communication and are not sent to the server, nor are they seen in a 'playerinfo'. If someone wants to run multiple login servers, we can come up with some sorts of 'vhosts' solution later.
3. This will also need some sort of implementation on the side of Doomseeker. I have an idea of how this works and can go into detail about this later.
4. At some point today I'll put this entire spec in its own little nicely-formatted document on bitbucket.
User avatar (0001309)
AlexMax (developer)
2011-04-08 05:06

 I started working on this tonight. You can track my progress here:

'https://bitbucket.org/alexmax2742/charon/ [^]'
User avatar (0001311)
AlexMax (developer)
2011-04-08 11:56
edited on: 2011-04-08 13:13

 Potential improvements:

1. We could use the secret to salt a hash of the password for over-the-wire transmission, like RCON does. This would force us to hash the password clientside ahead of time so its the same as the password stored in the database, but since we control the client this isn't onerous.
2. We could add an addition communication between client <-> charon and have the client wait for charon to return the secret before connecting, by which time we can reasonably expect the server to already have the authentication information and instead of kicking an unauthenticated player out simply set the auth information of the client as he's connecting.
3. We could also send back an "okay" from the server to charon after a successful authentication which would allow us to do some sort of charon-side player tracking (user X was last seen on server Y).
4. We could add a separate "signup page" query for doomseeker <-> charon communication. The doomseeker queries charon for the signup page for a specific server and charon returns it.

Question. Would using TCP be out of the question? Using TCP means we get message reliability UDP doesn't afford us. Plus if we decide to use SSL in the future TCP + SSL is _far_ more common.
User avatar (0001363)
kgsws (reporter)
2011-04-14 02:09
edited on: 2011-04-14 02:12

 Very simple, use HTTP (possibly secure) -> PHP solution.
Use POST or GET to login, use PHP session, same way as browser does it with cookies. This cookie will be player's ID valid for some time, client will send it to target server, server will simply check validity (if this PHPSESSID equals this client IP and maybe nickname).

Because of HTTP, it will be possible to use SSL.
Session data will contain login IP, so cookie stealing won't help anybody.
Login can be done in doomseeker. Doomseeker will give PHPSESSID in parameter to skulltag, not username and password. You will also directly join game. (i see it this way: skulltag -iwad doom2.wad -connect <server:port> -session <PHPSESSID>)
Because of PHP, it will be possible to use forum account as game login.

I can help if needed.
User avatar (0001364)
AlexMax (developer)
2011-04-14 03:39

 Being a web developer myself, a web service was the first thing that crossed my mind. However I realized that it would require servers to open up the existing ports to TCP as well as UDP, as well as require Skulltag to have a method of communication via TCP and would also require Skulltag to know how to form a valid HTTP request. By the time I revisited the login server idea again recently, I was almost done with my python huffman compression so I figured why not use a protocol that the skulltag client and server could easily implement.

I also see a few problems with your proposal. The biggest one is that if you send a session id to the server as a means of verification, all someone has to do is run a malicious server and grab any session ids that are sent to it, and all of the sudden the server has the users account and could log in to any other server or even steal the users account. However, using sessions at all means that now all of the sudden the login server is open to a whole new class of attacks (XSS and XSRF against the webapp that handles logins, poaching the session id en-route from client to login server and from login server to server). I already ran SSL by Torr and we both like the idea of challenge-response much better since it would be much more convenient for him to implement on the client and server. Also, just from a practicality standpoint, remembering a session id for an authenticated connect without a server browser is much harder than just a username/password, and if you're relying on the user to copypaste it out of the login app...well...that's even less secure.

Of course there will need to be a web interface for the login server, and I'm planning on writing it in flask or django. The idea of maintaining a PHP application for the purpose does not sit well with me at all.
User avatar (0001365)
kgsws (reporter)
2011-04-14 12:34
edited on: 2011-04-14 13:25

 > However I realized that it would require servers to open up the existing ports to TCP as well as UDP
Why UDP? Did i say something about UDP?

>Skulltag to have a method of communication via TCP and would also require Skulltag to know how to form a valid HTTP request.
How can this be problem? It is simple to make "fake" HTTP client that will just send request and process (find) required data.

> The biggest one is that if you send a session id to the server as a means of verification, all someone has to do is run a malicious server and grab any session ids that are sent to it, and all of the sudden the server has the users account and could log in to any other server or even steal the users account.
That is not right, session will contain your IP (ip from where you logged in), if someone steals this ID, it won't help anything, because of different IP.

>However, using sessions at all means that now all of the sudden the login server is open to a whole new class of attacks (XSS and XSRF against the webapp that handles logins, poaching the session id en-route from client to login server and from login server to server).
If you know what you are doing, you can protect your scripts against this.

> remembering a session id for an authenticated connect without a server browser is much harder than just a username/password, and if you're relying on the user to copypaste it out of the login app...well...that's even less secure.
Why? Skulltag can contain login function. There won't be login app, login can be dicrectly in doomseeker.

There is not any problem with HTTP way. It will be even easier to implement.
EDIT: very simple example, PoC
'http://zdoom.ic.cz/stauth.php?action=login [^]' // fail login
'http://zdoom.ic.cz/stauth.php?action=login&user=test&pass=onlytest [^]' // Correct login, doomseeker or in skulltag. I recommend using POST later, GET is here to show PoC.
'http://zdoom.ic.cz/stauth.php?action=logout [^]' // logout when you want
'http://zdoom.ic.cz/stauth.php?action=check&ip=<yourIPhere> [^]' // Server side check, you can use different browser but you need to use correct PHPSESSID cookie. If you put here your IP, authentication will pass, if not, client is using stolen cookie, authentication will fail.
'http://zdoom.ic.cz/stauth.php?action=info [^]' // debug info, this won't be in final script (ic.cz hosting sometimes use proxy for everyone)
'http://zdoom.ic.cz/stauth.php?action=source [^]' // show source of this script
User avatar (0001366)
AlexMax (developer)
2011-04-14 16:27

 The login server I'm writing is coming along nicely, hopefully by the weekend I can have something simple we can test against.

> Why UDP? Did i say something about UDP?
Skulltag uses UDP for all communication (game packets, remote rcon, server queries, etc.) HTTP uses TCP.

> How can this be problem? It is simple to make "fake" HTTP client that will just send request and process (find) required data.
It is simple to make fake HTTP client. However, your solution offers no over-the-wire security and SSL/TLS is much harder to implement from scratch. My solution handles the password securely without using SSL/TLS in the skulltag client/server communication. Also, the packets for my solution end up being smaller since there format is known ahead of time with no extra padding that using HTTP entails, and since we're using our own protocol we can compress it further using huffman coding (as opposed to gzip which is not as specialized).

> That is not right, session will contain your IP (ip from where you logged in), if someone steals this ID, it won't help anything, because of different IP.
Not necessarily. What if i'm on the same wireless connection (i.e. a coffee shop or college wifi)?

> If you know what you are doing, you can protect your scripts against this.
True, but PHP gives you 1,000 more ways to shoot your own foot off than most other languages, and you can't be sure that the guy who maintains it after you knows as much about the potential pitfalls. PHP is seductive because it's so simple to crank out a simple script in it, but when you need to scale your app it offers no advantages over other languages and quite a few more land-mines.

> Why? Skulltag can contain login function. There won't be login app, login can be dicrectly in doomseeker.
Then why are we passing raw session ID's around at the command line?

> There is not any problem with HTTP way. It will be even easier to implement.
My protocol is easier for the skulltag client/server/browser to implement (since skulltag's huffman coding already exists and the packets follow the same struct-based pattern that the other skulltag packets do) and the login server implementation itself is a quick study as well. You can see what I have so far here:

'https://bitbucket.org/alexmax2742/charon/src/tip [^]'

At this moment it is two files and a short unit test which tests the "handshake" functionality. I anticipate there being two more files (one for the huffman encoder/decoder, another as a place to separate CharonServer itself from the program main entry point).

Account creation and modification will be done in a separate app. This is someplace I _could_ use some help with, as I need some templates to make the registration app look nice.
User avatar (0001367)
kgsws (reporter)
2011-04-14 21:13

 > Not necessarily. What if i'm on the same wireless connection (i.e. a coffee shop or college wifi)?
Doing MITM attack only to steal player's temporary cookie? Being in same LAN does not give you access to this cookie, unless you are doing MITM attack, or you are owner of target server.

> Then why are we passing raw session ID's around at the command line?
To simplify login proces, you can just connect to any server without loging in each time. But skulltag itself will also contain login function.

> My protocol is easier for the skulltag
It will need new aditions (functions) same as my idea. Even if skulltag already contains huffman encoding, it will still need to make new connection with different data than just game protocol.

> We could use the secret to salt a hash of the password for over-the-wire transmission, like RCON does. This would force us to hash the password clientside ahead of time so its the same as the password stored in the database
If anyone somehow breaks into database, it will be much more easier to login as different player, because client hash password on its side, and same hash is in database. (no hash breaking will be needed, no salt will help)

Of course your way will work. My idea is to make it easy on all sides, not just skulltag but also account server.
As you can see my PoC PHP script, is very simple, it can be adapted to use forum profile (from forum database) as login to game.
User avatar (0001368)
AlexMax (developer)
2011-04-14 22:00
edited on: 2011-04-14 22:15

 > Doing MITM attack only to steal player's temporary cookie? Being in same LAN does not give you access to this cookie, unless you are doing MITM attack, or you are owner of target server.
Yep:'http://tinyurl.com/3w3knv2 [^]'

> It will need new aditions (functions) same as my idea. Even if skulltag already contains huffman encoding, it will still need to make new connection with different data than just game protocol.
True, but it is less 'different' than an entirely new TCP + HTTP + SSL connection type.

> If anyone somehow breaks into database, it will be much more easier to login as different player, because client hash password on its side, and same hash is in database. (no hash breaking will be needed, no salt will help)
A database break-in means that the login server is in much bigger trouble than aliasing. In fact, aliasing on a server with a compromised hash will give away the fact that the database is compromised very loudly. I am more concerned about revealing original passwords. Many players use the same password in many different locations, and just because someone breaks in to the user database shouldn't mean that they have the original password.

However, I actually agree with you that challenge-response is not quite ideal for the very reason you suggested. In an ideal world, I think that the client <-> login server handshake should be done over TCP + SSL but using the same protocol I am proposing. But then again, I also think that doing master server queries over UDP was a mistake too, and that should be TCP as well (JSON-RPC to be precise). In any case, I found Torr this weekend on IRC and asked him which he preferred (since aside from that edge case C+R is secure enough) and he picked C+R over SSL. So there you go.

> Of course your way will work. My idea is to make it easy on all sides, not just skulltag but also account server.
I do not need help with the account server implementation itself. In fact, I want to do the bulk of it myself since I've been wanting to contribute code to Skulltag for a long time, but lack of time, experience and not knowing C++ prevented me from doing so.

> As you can see my PoC PHP script, is very simple, it can be adapted to use forum profile (from forum database) as login to game.
So can mine.

Something to think about...I do not know of any PHP forum software that uses something as strong as bcrypt. Most hashes that are popular in the PHP community (or heck, any forum software) are fast such as MD5 or SHA1, and many use a simple salt. A hash used for storing passwords should be slow. Also, I did not see anything to account for multiple login servers in your spec.

Using a PHP script as a login server in a non-web environment like Skulltag feels like trying to use a hammer to pound in a screw. It might work, but it feels less than ideal I think.
User avatar (0001369)
kgsws (reporter)
2011-04-14 22:54

 I don't see anything less ideal on this, if you plan to allow users to register accounts on web server, you will have to use PHP script too, just not for skulltag itself but for your custom server. My solution uses web server as only one server.

Maybe i see my way better because i already know how to do it.
User avatar (0001371)
kgsws (reporter)
2011-04-15 03:22

 Yes, i just presented my idea here and tried to defend it little, you did same.
Everyting is clear now i guess.
User avatar (0001373)
AlexMax (developer)
2011-04-15 12:19

 Who will be hosting the login server? I need to coordinate with them on deployment of the server
User avatar (0001389)
AlexMax (developer)
2011-04-17 19:37

 Here is an updated protocol, now in the wiki:

'https://bitbucket.org/alexmax2742/charon/wiki/Protocol [^]'

Something to note: all packets now have expected responses.
User avatar (0008468)
AlexMax (developer)
2014-03-31 01:03
edited on: 2014-04-16 02:21

 --- NOTE ---

A long period of time passed between the above posts and this one. This is actually continuation of a discussion started in issue 1176. I dunno how or why I continued the discussion here, but the protocol is almost completely different now.

------------

Running into some issues compiling the zandronum-server (with -DSERVERONLY=True) in the zandronum-accounts branch on linux:

Linking CXX executable ../zandronum-server
CMakeFiles/zdoom.dir/cl_main.o: In function `CLIENT_ProcessCommand(long, BYTESTREAM_s*)':
/home/alexmax/workspace/zandronum-accounts/src/cl_main.cpp:2743: undefined reference to `CLIENT_ProcessSRPServerCommand(long, BYTESTREAM_s*)'
CMakeFiles/zdoom.dir/network.o: In function `NETWORK_Construct(unsigned short, bool)':
/home/alexmax/workspace/zandronum-accounts/src/network.cpp:445: undefined reference to `NETWORK_AUTH_Construct()'
CMakeFiles/zdoom.dir/network.o: In function `NETWORK_GetPackets()':
/home/alexmax/workspace/zandronum-accounts/src/network.cpp:530: undefined reference to `NETWORK_AUTH_GetCachedServerAddress()'
CMakeFiles/zdoom.dir/network.o: In function `NETWORK_GetLANPackets()':
/home/alexmax/workspace/zandronum-accounts/src/network.cpp:619: undefined reference to `NETWORK_AUTH_GetCachedServerAddress()'
CMakeFiles/zdoom.dir/network.o: In function `NETWORK_LaunchPacket(NETBUFFER_s*, NETADDRESS_s)':
/home/alexmax/workspace/zandronum-accounts/src/network.cpp:662: undefined reference to `NETWORK_AUTH_GetCachedServerAddress()'
CMakeFiles/zdoom.dir/sv_main.o: In function `SERVER_GetPackets()':
/home/alexmax/workspace/zandronum-accounts/src/sv_main.cpp:1056: undefined reference to `NETWORK_AUTH_GetCachedServerAddress()'
/home/alexmax/workspace/zandronum-accounts/src/sv_main.cpp:1058: undefined reference to `SERVER_AUTH_ParsePacket(BYTESTREAM_s*)'
CMakeFiles/zdoom.dir/sv_main.o: In function `SERVER_SetupNewConnection(BYTESTREAM_s*, bool)':
/home/alexmax/workspace/zandronum-accounts/src/sv_main.cpp:1985: undefined reference to `SERVER_InitClientSRPData(unsigned long)'
CMakeFiles/zdoom.dir/sv_main.o: In function `SERVER_ProcessCommand(long, BYTESTREAM_s*)':
/home/alexmax/workspace/zandronum-accounts/src/sv_main.cpp:4306: undefined reference to `SERVER_ProcessSRPClientCommand(long, BYTESTREAM_s*)'
collect2: error: ld returned 1 exit status
make[2]: *** [zandronum-server] Error 1
make[1]: *** [src/CMakeFiles/zdoom.dir/all] Error 2
make: *** [all] Error 2
User avatar (0008471)
Torr Samaho (administrator)
2014-03-31 17:29

 I didn't adjust the cmake mechanism to use csrp and OpenSSL yet. So the account fork currently only compiles under Windows with VC++. When I find some time, I'll try to make the necessary additions for Linux compatibility.
User avatar (0008472)
Torr Samaho (administrator)
2014-03-31 19:47

 The account fork should now also work under Linux.
User avatar (0008541)
AlexMax (developer)
2014-04-11 22:42

 There are several missing 'break' statements in SERVER_AUTH_ParsePacket().
User avatar (0008542)
Torr Samaho (administrator)
2014-04-12 16:29

 Yeah, you're right. I added the missing breaks. Do you already have a login server so that I test whether the function works now?
User avatar (0008544)
AlexMax (developer)
2014-04-12 19:55
edited on: 2014-04-12 19:56

 I managed to the login server to a state where it could be tested last night, and unfortunately the password authentication did not work. When the auth server tried to check the client's proof, it throws an error and claims it doesn't match up.

I'm currently investigating what's going on here and whose fault it is. Will keep you updated. I can also get my server into a state where you can use it if you prefer.
User avatar (0008545)
Torr Samaho (administrator)
2014-04-12 20:12

 If you need help with the debugging, just let me know. In that case, it would surely be very helpful if I could run your server locally.
User avatar (0008582)
AlexMax (developer)
2014-04-16 00:39

 Fixed it. Mozilla's SRP library defined the message as:

    M1 = H(A, B, S)

It's supposed to be:

    M1 = H(H(N) xor H(g), H(I), s, A, B, K)

As soon as I fixed this in the library...well, see the attached screenshot. :)
User avatar (0008583)
AlexMax (developer)
2014-04-16 02:16

 Food for thought. Currently the verifiers are only run SHA256 with a random salt. This is not very secure and I would prefer not to go live with this. I think the way we could do this instead is to use PBKDF2 when calculating the x used in the verifier.

Unfortunately there is no easy way to slot in a completely new way to generate x in CSRP - you can just use a better single round of hashing. I think that we will have to modify the csrp library (and my node-srp library as well) to call a PBKDF2-style function in calculate_x(). The protocol will also need to be adjusted to account for the number of hash iterations inherent to PBKDF2.

However, that can wait until later. Now that we have a login server, we can discuss things like:

- ACS functions that can uniquely identify a player.
- How logging in should work from an Zandronum interface point of view.
- Other fun stuff.
User avatar (0009270)
Watermelon (developer)
2014-06-14 03:25

 Now that this is in the other ticket, might as well close this as a legacy to that gigantic account thread

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: Balrog

- Issue History
Date Modified Username Field Change
2011-02-15 22:20 AlexMax New Issue
2011-02-21 00:22 AlexMax Note Added: 0001110
2011-02-21 00:27 AlexMax Note Edited: 0001110 View Revisions
2011-03-26 15:38 Torr Samaho Note Added: 0001186
2011-03-26 15:41 Torr Samaho Note Edited: 0001186 View Revisions
2011-03-26 15:41 Torr Samaho Note Revision Dropped: 1186: 0000604
2011-03-27 05:31 AlexMax Note Added: 0001192
2011-03-27 05:38 tm512 Note Added: 0001193
2011-03-27 05:39 AlexMax Note Edited: 0001192 View Revisions
2011-03-27 05:39 AlexMax Note Edited: 0001192 View Revisions
2011-03-30 01:58 Torr Samaho Note Added: 0001226
2011-03-30 21:29 AlexMax Note Added: 0001236
2011-03-30 21:30 AlexMax Note Edited: 0001236 View Revisions
2011-03-30 23:50 Torr Samaho Note Added: 0001237
2011-03-31 12:15 AlexMax Note Added: 0001239
2011-03-31 12:28 AlexMax Note Edited: 0001239 View Revisions
2011-03-31 12:33 AlexMax Note Edited: 0001239 View Revisions
2011-03-31 12:53 AlexMax Note Edited: 0001239 View Revisions
2011-03-31 22:35 AlexMax Note Added: 0001243
2011-03-31 22:36 AlexMax Note Edited: 0001243 View Revisions
2011-04-01 00:33 Torr Samaho Note Added: 0001245
2011-04-07 02:57 AlexMax Note Added: 0001304
2011-04-07 11:49 AlexMax Note Added: 0001306
2011-04-07 11:49 AlexMax Note Edited: 0001306 View Revisions
2011-04-07 11:53 AlexMax Note Edited: 0001306 View Revisions
2011-04-07 11:55 AlexMax Note Edited: 0001306 View Revisions
2011-04-08 05:06 AlexMax Note Added: 0001309
2011-04-08 11:56 AlexMax Note Added: 0001311
2011-04-08 12:40 AlexMax Note Edited: 0001311 View Revisions
2011-04-08 12:46 AlexMax Note Edited: 0001311 View Revisions
2011-04-08 12:47 AlexMax Note Edited: 0001311 View Revisions
2011-04-08 13:12 AlexMax Note Edited: 0001311 View Revisions
2011-04-08 13:13 AlexMax Note Edited: 0001311 View Revisions
2011-04-14 02:09 kgsws Note Added: 0001363
2011-04-14 02:12 kgsws Note Edited: 0001363 View Revisions
2011-04-14 03:39 AlexMax Note Added: 0001364
2011-04-14 12:34 kgsws Note Added: 0001365
2011-04-14 13:24 kgsws Note Edited: 0001365 View Revisions
2011-04-14 13:25 kgsws Note Edited: 0001365 View Revisions
2011-04-14 16:27 AlexMax Note Added: 0001366
2011-04-14 21:13 kgsws Note Added: 0001367
2011-04-14 22:00 AlexMax Note Added: 0001368
2011-04-14 22:15 AlexMax Note Edited: 0001368 View Revisions
2011-04-14 22:54 kgsws Note Added: 0001369
2011-04-15 03:22 kgsws Note Added: 0001371
2011-04-15 12:19 AlexMax Note Added: 0001373
2011-04-17 19:37 AlexMax Note Added: 0001389
2014-03-31 01:03 AlexMax Note Added: 0008468
2014-03-31 17:29 Torr Samaho Note Added: 0008471
2014-03-31 19:47 Torr Samaho Note Added: 0008472
2014-04-11 22:42 AlexMax Note Added: 0008541
2014-04-12 16:29 Torr Samaho Note Added: 0008542
2014-04-12 19:55 AlexMax Note Added: 0008544
2014-04-12 19:56 AlexMax Note Edited: 0008544 View Revisions
2014-04-12 20:12 Torr Samaho Note Added: 0008545
2014-04-16 00:39 AlexMax Note Added: 0008582
2014-04-16 00:40 AlexMax File Added: login_success.png
2014-04-16 02:16 AlexMax Note Added: 0008583
2014-04-16 02:21 AlexMax Note Edited: 0008468 View Revisions
2014-06-14 03:24 Watermelon Relationship added related to 0001176
2014-06-14 03:25 Watermelon Note Added: 0009270
2014-06-14 03:25 Watermelon Status new => closed
2014-06-14 03:25 Watermelon Resolution open => fixed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker