Upcoming account system

[Watermelon]

Upcoming Account System

For those of you who aren't familiar with the talk that has been going around, there is going to be a competitive account system coming out for Zandronum in the near future.
So far this will be only competitive, but depending on the success it may be able to be moved to the mod scene.

- About the account system

The account system will be a server side stored module that keeps track of your stats in duels and ctf, and can be extended in the future to things such as clan rankings, tdm, or other game modes. Each person will have their own custom account with a username, a password, a clan and a team (team is unused right now but space is made for custom tourneys that may come up). Everytime you play, your stats will be updated accordingly. An account is not mandatory and you will be able to play without needing to login or use an account. The majority of us will probably use accounts, but you have no fear of being forced to use such an account.

You will still be able to alias unless the general community does not want to see aliasing done when logged in. How it will work is you will get a username, and logging in will index your account number -- nothing else (for now). Therefore your in game name can be whatever you want (you can even alias at this point in time), but your account name will have to stay the same on the server. Obviously once a name is taken, you can't get it. Since this will be an easily monitored base, if your name is known among the community and someone takes your name I will be able to easily fix that.

Associated with each account is a rank, which probably will be public -- making it slightly harder to alias if you're an epic destructo-machine in duels for example.
Furthermore, ranked matches are optional in duels, private CTF I'm not too sure. There will be no ranked in public CTF games.
It will be all handled in game via a Graphical User Interface with a mouse in game. Therefore, get excited!




- What it will contain

Each account will have a username, password, clan, team and stats per each map. This will consist of your common elements (flags, frags, deaths, pickups, drops, possibly sprees... let your imagination run wild here).

This will all be accessible in game (!) and through a website. The bot will generate your own dynamic webpage, and will generate pages probably for private CTF matches and clan scrims much like the IDL site has. It will all be automated, and you can view with your own pleasure. Maybe if the Zandro devs add server-side demos there could even be demo uploads. Who knows.

NOTE: There will be per-map stats, and then your overall stats (overall for duels, ctf...etc)




- Usernames/passwords (is my account safe?)

You will log in through a GUI (and mouse) by clicking on a keyboard on screen to enter your username/password. Sorry I can't plug directly into the keyboard you use but zdoom No'd that request and it's pretty complicated to do such a thing right now unless a dev wants to help integrate it into ACS.

Now entering that in each time would suck, so there will be a 'remember me' option.

Your password will NOT be stored in the servers. What I will be doing is hashing it up into a scrambled mess that cannot be 'unscrambled' and this will be stored on the server. I figure this is the safest thing to do, though if you forget your password then I will not be able to retrieve it (and in this case you'll have to manually come to me and get me to issue you a new password). Giving you the scrambled password would do nothing because if you enter that, then the scrambled pass will just get scrambled again leaving you locked out still.

Since you are pressing buttons on a screen, keyloggers won't be able to steal it (but screen recorders can).

Demos may possibly show the user/pass being entered, which is why I will be asking everyone to check the "remember me" box when the time comes (it will be on by default) so that demos won't record you entering it in.

If someone hacks your account somehow, there will be backups every so often and I'll just revert it. Furthermore we can go to the staff with the IP of the person and pursue further action if you're pissed off enough. You should really get your own custom password for this and not use 'one-pass-for-everything' for ultimate safety. I can only prevent so much.

If people want I could also make a 'lockout IP/logging in for account after X tries', though I'd be sort of shocked if someone tried brute forcing someones account on here.




- Location

This will so far only be happening on Best Ever servers. Jenova has been kind enough to let me have some server space on his epic server. No european servers are expected at this date (and would require construction of a self-communicating bot which would be a bit messy, but the idea is not off the table).
Feel free to thank him next time you see him when this gets rolling.




- Wbuild

Servers using this will be using wbuild, but there will be the option to play with the features turned off; your options will be as follows:

• Allow wbuild for both players (on by default)
• Disallow it for yourself
• Disallow it for everyone in the server

WBuild is a modification designed for competitive gameplay. Some people like some of the features, and may dislike some. My goal is to have everything optional so you can play completely vanilla if you wish.






Conclusion

This will not be happening in the immediate future because I'm quite busy with university work, though the foundation for everything above has been laid out and tested. Maybe in a few weeks if I'm lucky. Thus far all that really needs to be done is the ACS for communicating between you to/from the server and everything will be operational. The ranking system is a modified ELO ranking system (as seen in the world famous chess ranking system).

If you have any input you would like to share or ideas you think could be implemented, please feel free to post here. This may be a community standard one day as many mods would love to use an account system/connect to a database (much like Jumpmaze does, but here on a more epic scale hopefully).

I also need GUI graphics. If you want to contribute here, your work will go down possibly in history.

[Torvald]

OH man, shits getting real now. I'm so psyched for this!

[one_Two]

Thanks for doing this water, could you describe the problems with getting it to work on Euro servers a bit more?

[Watermelon]

Thanks for doing this water, could you describe the problems with getting it to work on Euro servers a bit more?

- Cost for a reliable good non-laggy server (requires dedicated since almost all VPS's are bad, which is >90$ USD usually)

- Communication (code-wise) with the main server (BE) that is hosting it would be extra work to ensure synchronization between both




Top point is limiting me the most.

Maybe Konar would be able to help but I do not want to name-drop him or make it seem like I expect any more of him than what he does for the community at the moment.

[Catastrophe]

Get excited guys, this is the beginning of something epic

[Hammerfest-]

Finally, some action.

This gonna b gud, dawgs.

[Ænima]

OH SHIT SON


Can't wait until this makes its way to us modders. I have so many ideas.

[Strych6]

let your imagination run wild here).

I'd love a (maybe optional graph) display of how many kills on each weapon. in further detail, it'd be important to display how many rockets fired to juxtapose with rocket kill count. As with bfg ball

A lot of these parameters could have a last effect on gameplay so careful!

[mr fiat]

WBuild is a modification designed for competitive gameplay. Some people like some of the features, and may dislike some. My goal is to have everything optional so you can play completely vanilla if you wish.

I am REALLY glad it is possible to disable this when it comes out, because I'm not really looking forward to this.

[Watermelon]

WBuild is a modification designed for competitive gameplay. Some people like some of the features, and may dislike some. My goal is to have everything optional so you can play completely vanilla if you wish.

I am REALLY glad it is possible to disable this when it comes out, because I'm not really looking forward to this.

Would you like to provide reasons why for discussions sake?

[Slyfox]

wooo accounts, yeaaaa; I can already tell how bad my K/d would be with my flag count
Also:
"I am glad this is optional, because this idea sucks and I thought I'd share my wonderful optimism with you guys in this thread"

[piratefinn]

I can see modders now using ACS to save stats such as where skills are spent etc., no more puke 511 :P

[HumanBones]

Glad to see it remaining optional. All you have to do is look at the other examples of how an account system turns from a cool way to collect stats to a way of controlling who plays your port to see how this just flat out does not work.

Some things that concern me: Even though I don't have to sign up for an account, will it be possible for this system to prevent people who don't have accounts from playing on certain servers? AND, can you ban specific accounts from servers? I would certainly hope not. If so, it's a dangerous and slippery slope if I've ever seen one, and I think we all have. If it is purely for the enjoyment of stats and all of that, then neat idea.

[Stall]

Yes.

This looks sexy awesome super cool fun times.

It will also show everyone I'm the best.... Jenova is the best too.... So is Sabertooth, no doubt about it!

[Jenova]

Yes.

This looks sexy awesome super cool fun times.

It will also show everyone I'm the best.... Jenova is the best too.... So is Sabertooth, no doubt about it!

Good call my friend, I am looking forward to this.

[Eonfge]

It's a very interesting system and I'm glad with your idea of implementation. I am a strong advocate of 'free in beer and in freedom' and it would be a shame if Zandronum would slide down too the ZDaemon standard.

Hope you can get the system to work and who knows what great things can come from it. As long as it's optional to hosts and clients.

[AlexMax]

I have long advocated an optional user identification system with ACS hooks, and think you've got a good thing going here. However, I take issue with your implementation:

You will log in through a GUI (and mouse) by clicking on a keyboard on screen to enter your username/password. Sorry I can't plug directly into the keyboard you use but zdoom No'd that request and it's pretty complicated to do such a thing right now unless a dev wants to help integrate it into ACS.

This seems to me like a gigantic mistake. Instead of implementing this through some sort of in-game wizardy, a much better idea would be to coordinate with Torr Samaho to implement some sort of server-login system into the client itself. For example, you could perhaps implement a simple menu screen that accepts a login and password entered via keyboard, and either bring it up immediately upon connecting to the server or have "Login to server" as an option in the "join game" menu.

Creating such a screen in the client seems to me like it would be trivial, making use of the menu system that is already there. The tricky part would be figuring out how to send the login packet securely, but since you would be dealing with actual packets instead of ZDoom wizardry, at least you have options at this point.

The downside is that it would mean that you would have to wait until 1.1 to use it, but when it finally comes out, the gains in user experience would be so worth it.

Now entering that in each time would suck, so there will be a 'remember me' option.

How is the "remember me" function going to work? How can it differentiate between two different clients who are at the same IP address? I think perhaps some sort of "cookie" might be possible by setting a clientside variable that you could use as a session identifier perhaps...

Your password will NOT be stored in the servers. What I will be doing is hashing it up into a scrambled mess that cannot be 'unscrambled' and this will be stored on the server. I figure this is the safest thing to do, though if you forget your password then I will not be able to retrieve it (and in this case you'll have to manually come to me and get me to issue you a new password). Giving you the scrambled password would do nothing because if you enter that, then the scrambled pass will just get scrambled again leaving you locked out still.

I must insist that you use bcrypt as your hashing function. :)

Since you are pressing buttons on a screen, keyloggers won't be able to steal it (but screen recorders can).

Note that a targeted attack is possible simply by listening in on network traffic, since Skulltag Client <-> Skulltag Server traffic is not encrypted at all.

If someone hacks your account somehow, there will be backups every so often and I'll just revert it. Furthermore we can go to the staff with the IP of the person and pursue further action if you're pissed off enough. You should really get your own custom password for this and not use 'one-pass-for-everything' for ultimate safety. I can only prevent so much.

If people want I could also make a 'lockout IP/logging in for account after X tries', though I'd be sort of shocked if someone tried brute forcing someones account on here.

I would go ahead and implement this anyway. I imagine someone with knowledge of Zandronum's network protocol could cook up a headless bruteforcer pretty trivially, why leave it to chance.

This will so far only be happening on Best Ever servers. Jenova has been kind enough to let me have some server space on his epic server. No european servers are expected at this date (and would require construction of a self-communicating bot which would be a bit messy, but the idea is not off the table).

You might want to revisit my idea of a separate login server:

- Client connects to Server
- Server sends back login token X.
- Client sends login token X and user/pass to third-party login server
- Third party login server verifies or denies the client.
- Third party login server sends a message to Server saying Client with login token X is accepted/deined.

[Watermelon]

You will log in through a GUI (and mouse) by clicking on a keyboard on screen to enter your username/password. Sorry I can't plug directly into the keyboard you use but zdoom No'd that request and it's pretty complicated to do such a thing right now unless a dev wants to help integrate it into ACS.

This seems to me like a gigantic mistake. Instead of implementing this through some sort of in-game wizardy, a much better idea would be to coordinate with Torr Samaho to implement some sort of server-login system into the client itself. For example, you could perhaps implement a simple menu screen that accepts a login and password entered via keyboard, and either bring it up immediately upon connecting to the server or have "Login to server" as an option in the "join game" menu.

Creating such a screen in the client seems to me like it would be trivial, making use of the menu system that is already there. The tricky part would be figuring out how to send the login packet securely, but since you would be dealing with actual packets instead of ZDoom wizardry, at least you have options at this point.

The downside is that it would mean that you would have to wait until 1.1 to use it, but when it finally comes out, the gains in user experience would be so worth it.

Great stuff here!

If it helps:
- There's currently a tracker ticket for openSSL: http://zandronum.com/tracker/view.php?id=1176
The only problem is I'm unfamiliar with how to run/compile this properly, though I think this option would definitely be the best. Adding the stuff to the menu would be I think quick and easy, I just don't know about the openSSL part. If someone could do a quick confirmation it'd speed this up a lot.

Ideally I'd rather go the route you said above, because rather than me making some obscure huge-coded module, it'd be nice and easy to get accounts through it, and then just have ACS deal with the other stuff.

Now entering that in each time would suck, so there will be a 'remember me' option.

How is the "remember me" function going to work? How can it differentiate between two different clients who are at the same IP address? I think perhaps some sort of "cookie" might be possible by setting a clientside variable that you could use as a session identifier perhaps...

I was thinking of doing that for people who share a computer. It'd probably have to store it in an .ini file somewhere. The only problem with this is that someone could go through it. I was going to hopefully write some kind of obfuscation with ACS to make it safer but someone if they had enough time and patience could crack it. That's why I'd love the openSSL part because it removes the headache here.

Your password will NOT be stored in the servers. What I will be doing is hashing it up into a scrambled mess that cannot be 'unscrambled' and this will be stored on the server. I figure this is the safest thing to do, though if you forget your password then I will not be able to retrieve it (and in this case you'll have to manually come to me and get me to issue you a new password). Giving you the scrambled password would do nothing because if you enter that, then the scrambled pass will just get scrambled again leaving you locked out still.

I must insist that you use bcrypt as your hashing function. :)

I'm definitely going to be using this instead, I found out apparently md5's can be cracked easily with a good enough computer

This will so far only be happening on Best Ever servers. Jenova has been kind enough to let me have some server space on his epic server. No european servers are expected at this date (and would require construction of a self-communicating bot which would be a bit messy, but the idea is not off the table).

You might want to revisit my idea of a separate login server:

- Client connects to Server
- Server sends back login token X.
- Client sends login token X and user/pass to third-party login server
- Third party login server verifies or denies the client.
- Third party login server sends a message to Server saying Client with login token X is accepted/deined.

[/quote]

I'm hoping that the openSSL if implemented would do this. I think this would communicate with the master server, would that be your third party server?

[AlexMax]

You will log in through a GUI (and mouse) by clicking on a keyboard on screen to enter your username/password. Sorry I can't plug directly into the keyboard you use but zdoom No'd that request and it's pretty complicated to do such a thing right now unless a dev wants to help integrate it into ACS.

This seems to me like a gigantic mistake. Instead of implementing this through some sort of in-game wizardy, a much better idea would be to coordinate with Torr Samaho to implement some sort of server-login system into the client itself. For example, you could perhaps implement a simple menu screen that accepts a login and password entered via keyboard, and either bring it up immediately upon connecting to the server or have "Login to server" as an option in the "join game" menu.

Creating such a screen in the client seems to me like it would be trivial, making use of the menu system that is already there. The tricky part would be figuring out how to send the login packet securely, but since you would be dealing with actual packets instead of ZDoom wizardry, at least you have options at this point.

The downside is that it would mean that you would have to wait until 1.1 to use it, but when it finally comes out, the gains in user experience would be so worth it.

Great stuff here!

If it helps:
- There's currently a tracker ticket for openSSL: http://zandronum.com/tracker/view.php?id=1176
The only problem is I'm unfamiliar with how to run/compile this properly, though I think this option would definitely be the best. Adding the stuff to the menu would be I think quick and easy, I just don't know about the openSSL part. If someone could do a quick confirmation it'd speed this up a lot.

Ideally I'd rather go the route you said above, because rather than me making some obscure huge-coded module, it'd be nice and easy to get accounts through it, and then just have ACS deal with the other stuff.

CMake has a FindOpenSSL module built-in.

That said
- OpenSSL has a reputation for being obtuse and poorly documented
- SSL itself relies on TCP, which is unsuitable for an unreliable datagram transport protocol such as UDP.
- DTLS is a thing that exists and is supported by OpenSSL, but again, see my first point.
- As awfully complicated as OpenSSL is, inventing your own form of encryption is almost always a bad idea.
- Encrypting the entire data stream between the client and server would be silly.  All we really care about is making sure nobody can sniff somebody's password in plaintext over-the-wire.

What's the solution? Heck if I know, I've been googling for an hour without any good solutions...yet. But the fact that you have access to the sent packet means that you at least have the option open, so you can punt on the question sending the password over the wire securely until later.

[Fluffles]

Bring on ranked duel matchs . Oi water you done my OS server yet fool. That one will require ranking once this is available ;)