You should get a job as a software tester... if you can convince a company to trust you.

[-z-] wrote:You should get a job as a software tester... if you can convince a company to trust you.

The getting a good/real job part seems unrealistic. The bottom is falling out from everything. Also the only job experience I have is 2 retail jobs and a work-study program. My 4 yr degree is in buisness and is worthless. I don't think there is any possibility of me ever getting a good job. I will probably always be in retail untill 30, which is surely when life ends as I've been told.

Why not just show them some of your internet triumphs? Build a portfolio of your smarts.

[-z-] wrote:Why not just show them some of your internet triumphs? Build a portfolio of your smarts.

What triumphs?

Anyway, back to topic.

The big problem with passworded servers is abuse of that feature by changing the engine to ALLOW them to be registered on the master server.

And I know that many people want that.

Although the author of this thread proposes a patch that does make the server forcefully non-public, it's trivial to remove that code and allow passworded servers to clog the server list, which would be a GREAT annoyance to everyone.

Before accepting such a patch, we'd need some automated means to safely check whether a server is passworded, and have the master server (dpmaster) reject entering passworded servers.

An idea for this would be doing the password check not in the "connect" request, but already in the "getchallenge" one. That command can be used at any time, and it does not fail if the server is full. The master server therefore could easily use it (e.g. after every heartbeat packet) to verify the server and to keep passworded servers out.

I do not demand that the master server be changed NOW for this. This can be done later once such abuse is there. But if the password protection is moved to the "getchallenge" stage, nobody would be able to easily hack his server so it successfully registers into the public server list once that dpmaster change would be made.

Still, the gaping security holes in this patch need to be changed anyway (especially that join_password is easily sent to a server the PW is not intended for, and that server could log the password then). Stuff that IMHO has high priority before this is:

- SSL encrypted connections (e.g. using DTLS from OpenSSL). But I gave up on that part due to lack of documentation (only usage of OpenSSL for stream protocols is documented). With this, client and server certificates.
- If this is REALLY rejected, and not pushed away until someone else comes with OpenSSL and DTLS experience who can do it: hashed passwords for rcon. But this is bad, as it would still allow MitM attacks.

BTW, the problem mikeeusa is referring to is crappy providers in the USA. In civilized countries, someone who signs up at an ISP - be it modem, DSL, whatever - is restricted to only send packets from his own assigned IP, and can't send e.g. ARP replies to other customers of this ISP. Apparently, in the USA, the concept "cable modem" is prevalent, and it means that whole streets or blocks are in a single LAN segment, and can freely ARP spoof each other (and programs like ettercap do exactly that). And the chance to find one badly configured computer in a whole /24 subnet is very high (e.g. chances are high that one or more of them are trojaned or have bad passwords), and from there you can sniff on your actual victim.

On a bit of a related note, one of the features I have been looking for is a way to allow admins (having the rcon password) to join a server even when it's full.

Only being able to use this from the console would be fine (for example connect x.x.x.x:26000 <rcon_pssswd>). This way normal players will not have to know about this behaviour (as they won't get actively prompted for the password).

About the encryption bit, it seems more logical in this case to use PBKDF (like PKCS #11) than to use full DTLS. DTLS is there to encrypt an UDP packet sequence (not in a stream, but still multiple packets), while PBKDF let's derive a key from the password - which can be used as the key for AES to re-encrypt the challenge. If the server generates the same aes encrypted sequence - they have the same password.

I'd be willing to take a stab at this when I have some free time.

merlijn wrote:About the encryption bit, it seems more logical in this case to use PBKDF (like PKCS #11) than to use full DTLS. DTLS is there to encrypt an UDP packet sequence (not in a stream, but still multiple packets), while PBKDF let's derive a key from the password - which can be used as the key for AES to re-encrypt the challenge. If the server generates the same aes encrypted sequence - they have the same password.

I'd be willing to take a stab at this when I have some free time.

Then you hijack an existing player connection rather than creating your own.

Also with that you only "gain" the advantache of douch-servers without the advantage of privacy amonst connected users and difficulty in vandalism/tomfoolery/haxing that full encryption allows: you never know when someone will private message something they could later regret to someone (and wish it was just between them (bob+alice+serveradmin), rather than them and whatever is recording their conversation free in the clear (bob+alice+serveradmin+skriptkiddie+intrepidhaxplayer+everypoliceorganization)...

Basically its having telnet with "secure" passwords vs having SSH. Once you're authenticated anyone can still do whatever they want by hijacking your connection. Also since the connection is not interrupted (it is forwarded both ways) to the original user that user can still respond to any auth challenges sent down the line later.

tundramagi wrote:Then you hijack an existing player connection rather than creating your own.

Also with that you only "gain" the advantache of douch-servers without the advantage of privacy amonst connected users and difficulty in vandalism/tomfoolery/haxing that full encryption allows: you never know when someone will private message something they could later regret to someone (and wish it was just between them (bob+alice+serveradmin), rather than them and whatever is recording their conversation free in the clear (bob+alice+serveradmin+skriptkiddie+intrepidhaxplayer+everypoliceorganization)...

Basically its having telnet with "secure" passwords vs having SSH. Once you're authenticated anyone can still do whatever they want by hijacking your connection. Also since the connection is not interrupted (it is forwarded both ways) to the original user that user can still respond to any auth challenges sent down the line later.

You're right in that it would still be possible to inject, or alter packets after the authentication step. The advantage is that the password itself never travels over the line. The way to resolve this would be to add a verification key to rcon passwords, for example using the AES cipher in CBC mode and forcing a re-auth whenever a failed verification was received. This would extend the packetsize with 16 octets and could be comprised of first generating the md5sum over the contents of the packet, and encrypting this with the 128-bit AES cipher. This would result in quite secure authentication.

Encryption just seems like it's over the top for this kind of traffic, and the problem with DTLS is still that if you manage to decrypt the auth-packet, you will have all the information you need to authenticate yourself.

A session takeover attack for darkplaces and other NQ protocol engines already exists. Can be used e.g. to inject a svc_stufftext message on a client that executes a quake console command (like "quit").

Only disadvantage of this attack is that it's not covert - doing this will for sure kill the connection afterwards (but you can time it right before a map change and send a "connect" command so the client won't notice).

So if you're going to "authenticate first, rcon afterwards", it means one can easily inject rcon packets.

IMHO rcon packets should be digitally signed by the issuer, and only a single packet should be sent for them.

For in-game security (including join_password, session takeover can also make you able to play), one would have to encrypt the whole connection.

divVerent wrote:Personally, I have absolutely no interest in this feature, as it's really not a good idea to do this in an open source game.

I'll give you a real-world example of why this would be useful.

I run some private servers that are quite popular. I have had one particular individual connect to my server and act like an ass to everybody. I've banned him by IP address multiple times. He just gets a new one from his ISP. I've ended up banning mutliple IP ranges with iptables. This is not ideal to me, because I also run a public server on the same box and I don't know how many people might be affected by that banning.

So divverent, what would you have me do to keep this guy off my private servers? I could change the ports, but then I would not be able to have a webpage about the servers that shows the list of players because someone could discover the port # through that page.

It seems that the best option is to password protect the server. Sure, they could discover the password by someone accidentally leaking it to them, and then I would have to change the password and notify everyone again, but this is the only thing I can imagine that would work.

Then why do you put IP and port number on a public web page, if you want it private?

You see the danger of this feature - blocking the game for almost everyone except few people who stuck around for years? Because, you know, once a feature is there, people start using it.

The only way I'd accept this feature into Nexuiz is with an unhackable means to prevent passworded servers from appearing in the public server list - or at least a provision for that so such filtering can be added to dpmaster later without changing the engine.

Actually, I found an even better way.

On "getchallenge", passworded servers shall return a "pwchallenge", and not just a "challenge". The challenge string is then also used for hashing the password, which is then sent in the "connect" message.

A master server can then verify in a foolproof way whether a server is passworded: it just issues a "getchallenge" request on reply to heartbeats, and only add the server if a "challenge" came back, but not if a "pwchallenge" came.

Its main improvement will be that the password is never sent plain - and the same sequence could also be used for a more secure rcon (then, you'd use getchallenge, accept BOTH challenge and pwchallenge, and encrypt the rcon password using that).

divVerent wrote:Then why do you put IP and port number on a public web page, if you want it private?

It's just an information page about the servers.

I'm using this....
http://planetnexuiz.de/qstat/popup.rb?serverIP:26001
to display the current status of each server within an iframe on the page.

Rather than use an external site, I could write my own code to do this without displaying the IP/port, but my programming knowledge is not at that level yet.

Dokujisan wrote:

divVerent wrote:Personally, I have absolutely no interest in this feature, as it's really not a good idea to do this in an open source game.

I'll give you a real-world example of why this would be useful.

I run some private servers that are quite popular. I have had one particular individual connect to my server and act like an ass to everybody. I've banned him by IP address multiple times. He just gets a new one from his ISP. I've ended up banning mutliple IP ranges with iptables. This is not ideal to me, because I also run a public server on the same box and I don't know how many people might be affected by that banning.

So divverent, what would you have me do to keep this guy off my private servers? I could change the ports, but then I would not be able to have a webpage about the servers that shows the list of players because someone could discover the port # through that page.

It seems that the best option is to password protect the server. Sure, they could discover the password by someone accidentally leaking it to them, and then I would have to change the password and notify everyone again, but this is the only thing I can imagine that would work.

You know that you can block IP's per port and per protocol with IP tables right? You can just ban the internet from the port that you run your private server on and not the port that you run your public server on. You can make these bans UDP exclusive, you can also configure them to silently drop packets from whoever you hate. (I _ALWAYS_ use the silent drop option when I " 'table " some IP range rather than the friendly disconnect (the normal ban type) option: this is because I want their connection to hang rather than just immedatily know it's not wanted: I want to waste their time as they try again and again to connect to whatever service they are banned from and get NO response WHATSOEVER (:D ) from the server: as if it dropped off the internet.

You can also, by default, drop all traffic to that port, and then selectiively allow traffic from the people you would theoretically give the password to. You set the drop iptable first, then after that line set ones that allow traffic through per ip. See, no need for password! (Ettercap connection hijacking, if one knows who any of the people are who are allowed into your server, and gains access to any computer on their LAN or Cable Lan segment (or router), still works, so no matter what without encryption your sunk against anyone who has any knowlege that tools to do such exist.)

Remeber: ALWAYS use the DROP option so you waste the time of whatever huge section of the internet you are banning. You WANT to waste their time as they wonder WHY there is NO response from your computer to theirs ! Deny == polite == NO!

divVerent wrote:An idea for this would be doing the password check not in the "connect" request, but already in the "getchallenge" one. That command can be used at any time, and it does not fail if the server is full. The master server therefore could easily use it (e.g. after every heartbeat packet) to verify the server and to keep passworded servers out.

I do not demand that the master server be changed NOW for this. This can be done later once such abuse is there. But if the password protection is moved to the "getchallenge" stage, nobody would be able to easily hack his server so it successfully registers into the public server list once that dpmaster change would be made.

This would be annoying to enter the password only to get the information that the server is full. Why just simply not adding another filtering option and a lock icon to show which servers
are pp if show password protected servers is checked.

Alien wrote:

divVerent wrote:An idea for this would be doing the password check not in the "connect" request, but already in the "getchallenge" one. That command can be used at any time, and it does not fail if the server is full. The master server therefore could easily use it (e.g. after every heartbeat packet) to verify the server and to keep passworded servers out.

I do not demand that the master server be changed NOW for this. This can be done later once such abuse is there. But if the password protection is moved to the "getchallenge" stage, nobody would be able to easily hack his server so it successfully registers into the public server list once that dpmaster change would be made.

This would be annoying to enter the password only to get the information that the server is full. Why just simply not adding another filtering option and a lock icon to show which servers
are pp if show password protected servers is checked.

Because if password protected servers were allowed to be listed on the listservers then the majority of the servers would be configued to be password protected.

tundramagi wrote:Because if password protected servers were allowed to be listed on the listservers then the majority of the servers would be configued to be password protected.

Yeah, I'm sure that with 80% of servers already having 0 players, the admins would jump on this to ensure no one ever joins.

Demonstrated in FOSS shooters such as AssaultCube and Tremulous, password protection is present on a minority of servers, less than the 20% extreme for Warsow's cyper-athletics.

Master servers are for listing active servers, it is much better rely on passwords rather than IP:PORT secrecy, an incorrect IP will lead to a connection attempt and ~10 timeout, or connection to another server instance on a different port; inputting a password into a master server listed guarantees intended connection if password in correct.

Remembering a hostname and password is also easier than an remembering an IP:PORT, furthermore, anyone willing to sniff packets has already exceeded the experience and determination threshold for finding unlisted IP:PORT addresses.

TVR wrote:Demonstrated in FOSS shooters such as AssaultCube and Tremulous, password protection is present on a minority of servers, less than the 20% extreme for Warsow's cyper-athletics.

Master servers are for listing active servers, it is much better rely on passwords rather than IP:PORT secrecy, an incorrect IP will lead to a connection attempt and ~10 timeout, or connection to another server instance on a different port; inputting a password into a master server listed guarantees intended connection if password in correct.

Remembering a hostname and password is also easier than an remembering an IP:PORT, furthermore, anyone willing to sniff packets has already exceeded the experience and determination threshold for finding unlisted IP:PORT addresses.

Use your firewall to firewall all but the peeps you want playing, Done. No password needed. Please don't put that server on as public though either.

Oh and if you think sniffing exceeds anything... no experiance is required: ettercap and friends do everything. You do not need to know anything. The only thing that can ever save you is proper encryption of the datastream, sometimes. There is no point to passwording when someone can 'cap your unsecured wide open free and in the clear connection.

The bottom line is this:
People are lazy, yes they are. If there was an option to either create a server with password, or mingle with the firewall, ports, forwarding etc. of course people would choose the password route.
Even hackers are lazy, they don't always wish to hack a passworded servers, they don't always care.
Also, if you have a server that doesn't necessarily mean you have access to the firewall. Your server might sit at some company or at some friend or even paying for a online server service. Passwords are a good thing, with or without encryption cause they always filter out some unwanted people.

Don't make it sound like passwords are a bad thing (even without encryption) cause that's not the case. Sure I know passwords and stuff can entice people to hack it, but this has yet to be tried before jumping to conclusions.
Don't rule something out before you've tested it.

they are a bad thing, as UT shows.

Showing them in the server list - only if they're filtered out BY DEFAULT. If one click enables showing them, fine. But by default, they must be hidden to not turn this game into a passworded-servers-only game like UT99 has become.

divVerent wrote:they are a bad thing, as UT shows.

Showing them in the server list - only if they're filtered out BY DEFAULT. If one click enables showing them, fine. But by default, they must be hidden to not turn this game into a passworded-servers-only game like UT99 has become.

I can agree with this.

ai wrote:Don't make it sound like passwords are a bad thing (even without encryption) cause that's not the case. Sure I know passwords and stuff can entice people to hack it, but this has yet to be tried before jumping to conclusions.
Don't rule something out before you've tested it.

So... how's telnet treating you?

tundramagi wrote:So... how's telnet treating you?

Not treating me at all, I don't use telnet or any other terminal like that. I'm an artist, not a coder/programmer. I'm not even that smart, I use Linux Mint as it suits me very well.

tundramagi wrote:... Use your firewall to firewall all but the peeps you want playing, Done. No password needed. ...

Whitelisting is a two way exchange, their IPs must be provided back before they join, rather than just distributing the passwords.

tundramagi wrote:... no experiance is required: ettercap and friends do everything. You do not need to know anything. The only thing that can ever save you is proper encryption of the datastream, sometimes. ...

Sniffing for IPs is easier than sniffing for passwords.

The only information that cannot be encrypted is the IP:PORT address.

ai wrote:... If there was an option to either create a server with password, or mingle with the firewall, ports, forwarding etc. of course people would choose the password route. ...

Whether the server is intended to be a 'pub' or private must be considered.

Anyone operating a server intended for everyone is already willing to forgo the existing measures of exclusion.

Anyone wanting a server that can easily be joined by certain people only, should not be deceived into allowing anyone to join the server due to bigotry.

divVerent wrote:... to not turn this game into a passworded-servers-only game like UT99 has become. ...

The only reason why UT99 possesses a passworded server majority is because there exist NO new players, the only explanation why there is no influx is because UT99 is obsolete in the wake of sequels, UT2004/UT3 in particular.

Nexuiz will always attract new players, it is irreplaceable as a FOSS Quake/UT arena shooter with pretty graphics and innate portability.

TVR wrote:Anyone operating a server intended for everyone is already willing to forgo the existing measures of exclusion.

Anyone wanting a server that can easily be joined by certain people only, should not be deceived into allowing anyone to join the server due to bigotry.

True. But there should be another way to make private servers easily joinable than by spamming the public server list with them to the annoyance to the majority of the players.

Possible better solutions I see:
- a link from a website that directly starts Nexuiz with that IP (in other words, we'd need someone to write an URL handler for Windows that starts Nexuiz with the given IP, and possibly transmits a given password)
- a name-resolve protocol that allows to find private servers by name (HEY, WE ALREADY HAVE THAT, "connect foo.dyndns.org")
- or, hiding them behind a checkbox to filter them out by default (and when it's clicked, only passworded servers are shown so they can be easily joined)

Actually, why not go for the website link option? There's already telnet://, so why not nex://?

divVerent wrote:... to not turn this game into a passworded-servers-only game like UT99 has become. ...

The only reason why UT99 possesses a passworded server majority is because there exist NO new players, the only explanation why there is no influx is because UT99 is obsolete in the wake of sequels, UT2004/UT3 in particular.

Then tell me why these servers are passworded, if there's no punks to worry about.

Also, Quake did not degenerate into this sorry situation - because Quake had no passworded server feature.

If we had some centralized server with user auth data then we could make awesome skill statistics and "experience" and medals and lots of stuff.

Just saying...

divVerent wrote:... Then tell me why these servers are passworded, if there's no punks to worry about. ...

Given an obsolete game played occasionally, it's more efficient to distribute passwords to the few occasional players than for an admin to watch the server.

There are still are instances of TK'ing, cheating, and other forms of grieving present in old online games, people are still being kicked from Q3 servers.

divVerent wrote:... Also, Quake did not degenerate into this sorry situation - because Quake had no passworded server feature. ...

The original Quake has degenerated into ~7 servers, I personally have never seen any players on those servers. Quake 2 is the successor to Quake, and has accreted the playercount.

Both Unreal Tournament & Quake 3 Arena were released during the same era, both games feature password protection, Q3 arena still has 'pubs' because there is not a similar, but improved arena shooter to succeed it.

Quake 3 is alive not because of oa, but rather it's comps are still held (cpma) and now quakelive.

Alien wrote:Quake 3 is alive not because of oa, but rather it's comps are still held (cpma) and now quakelive.

I wouldn't expect anyone who already has Q3 Arena to play QuakeLive, the same game but with advertisements.

Q3 Arena still has a niche because there is no Quake 5 Arena.

alpha wrote:If we had some centralized server with user auth data then we could make awesome skill statistics and "experience" and medals and lots of stuff.

Just saying...

And then anyone that whoever controls that server doesn't like gets banned from playing nexuiz. Ah, I see why some people like the idea.