Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 03 Jun 2003
Offline Last Active Today, 08:36 PM

#5092380 hplus' Authentication for Games

Posted by hplus0603 on 07 September 2013 - 07:45 PM

  1. Client connects to game server and transmits the auth ticket. Doesn't this already need to be encrypted to prevent against sniffing on open networks? But the server apparently doesn't retrieve the encryption key till later, so what is stopping someone else grabbing the ticket and connecting as you?
  2. Is there any reason not to start the sequence numbers at 0 given we already using a random encryption key?
  3. Aren't sequence numbers going to be fairly useless with UDP unreliable messages?
  4. What is a suitable hash for ongoing messages once authentication has been established? I assume this is really just a checksum to make sure the data hasn't been tempered with.

Also, would you still give the same advice today? Reading the archives here I get the feeling should really be looking at TCP/TLS instead, if at all possible...



1. Unless the player is playing the game on an open WiFi network, it is actually pretty hard to "tap into" the network connection and sniff the ticket. So, the question is whether your attack vector includes those with physical access to the networking infrastructure. If the ticket is tied to a remote IP address, then even stealing the ticket is not good enough unless you can also steal the IP address. It turns out that modern day use cases like the open WiFi on Starbucks and McDonald's and similar places allow you to do both, though (like Firesheep,) so using transport-level encryption is advisable if you want to protect against that.


2. If you have some other way to detect replay attacks or blind data injection, then the sequence number can start at 0 every time.


3. Sequence numbers are highly useful for UDP, because they let you know which of your packets make it through, and which ones don't.


4. If the goal of the "hash" is to protect against network-level hardware corruption, a crc32 would be fine. If the goal is to protect against a determined attacker with the capability of acting as a man-in-the-middle, then a HMAC with a shared secret and a strong algorithm is needed. A straight hash with a shared secret is not good enough, because the attacker can use hash data extension to inject his own data at the end of the message. HMAC fixes this. Btw; using md5 for the HMAC algorithm would let someone inject data as well, because creating 16 bytes at the end of a packet that achieves the HMAC you want with MD5 is no longer a computationally hard problem. I'd suggest sha-1 for now, for games, although if you're all security-minded, by all means use sha-256. And hope the NSA isn't interested in cheating in your game :-)


If you're using TCP, then TLS is a fine transport mechanism, but it does not solve the authentication problem by itself.

If you're prepared to set up unique client certificates for each client, you can do that, though. if you want to go that route, that would be a perfectly fine alternative, as far as I know. (I e: it's likely that self-signed self-issued certificates from an audited code base will be secure; it's also likely that pay-for CAs are by now not considered 100% secure.)

IIRC, you also can't really use UDP with the TLS stack as it uses full-stream in-order CBC.


All of which goes to the question: What kind of attacks are you *really* trying to defend against? If your game is a valuable target, it's much easier to install malware on your players' computer, than it is to do a cryptographic attack.


#5091899 Network buffer, eNet and congestion.

Posted by hplus0603 on 05 September 2013 - 04:06 PM

Also, some general advice: If you don't know how to debug your project, your project is a failure waiting to happen. Knowing how to debug something is a very important factor to consider when choosing vendors/libraries/technologies/languages!

#5091802 Network buffer, eNet and congestion.

Posted by hplus0603 on 05 September 2013 - 09:38 AM

I think Enet limits the throughput of data sent. Check how much data you are sending (in bytes per second) when it stops working.

Also, look at the packets using Wireshark or tcpdump, and try to match them up to the data you are sending, to see what's going on.

If all else fails, you can always step into the code and figure out what's going on!

#5088931 Data compression/optimization strategies

Posted by hplus0603 on 25 August 2013 - 10:30 AM

The most compact data is the data that you do not send.

Work very hard on not sending data.

Why send position every update when you can send position when starting out, and then just send player (or object) inputs, and run the simulation on the client, for example?


When it comes to "string ids," presumably those are known in advance, and can be sent as a small index into a look-up table.

If they are not, then you can build a dynamic string table (per connection.)

When sending a string, first look it up in a hash table. If there is a "previous ID" for that string, then send only that ID. Else, allocate a new ID, and send a command saying "here's a string and here's the ID I will use when referring to it again."

Strings that contain ever-changing data (like object IDs or timestamps or coordinates) are a bad match for this pattern, though.

#5088775 Server-side technology to handle time-based games

Posted by hplus0603 on 24 August 2013 - 08:14 PM

You can do all simulation on the server, yet not have to do processing unless a client is logged on.

Most FarmVille type games can be simulated in almost zero time.

Thus, you can remember when the server last saw the player.

When next a player asks for a status update, read the last state you saw, compare the current time to the time that was saved, and fast-forward the state to the new point.

In fact, you can build all of FarmVille as simple web requests.

The client would send any commands being performed as POSTs to the game state.

The client would ask for a status update (using GET) every so often, which would make the server calculate a new state.
The client can simulate time on its own, too, and only ask for an update when it knows something is supposed to have changed.
This is totally cheat proof, because if you ask for an update too often, the server will just notice that nothing has changed since the last time, and return the appropriate game state.

#5085348 Trying to find great texts on network programming

Posted by hplus0603 on 12 August 2013 - 08:21 PM

The FAQ for this forum has a reasonable list of links.


For a networking textbook that focuses on networked physics more than, say, SQL databases or HTTP, try "Networked Virtual Environments" by Singhal et al. Note that it still won't teach you everything about things like how to ensure a proper deterministic simulation engine for lock-step, etc -- you pretty much have to scour the net for various blog posts and links for that. (Again, links in the FAQ help)

#5085053 Problem receiving packets

Posted by hplus0603 on 11 August 2013 - 05:37 PM

sizeof(message) is 4 or 8 depending on your architecture. It's unlikely to be what you actually mean.


Also, is "handle" a valid socket? Is it bound to the port that you're trying to send to, before you try to send?


What values do the calls to sendto() and recvfrom() actually return?


Finally, you typically want to memset() the "address" to 0 before starting to fill it out. This used to matter on some implementations (even though it shouldn't.) I don't know if it still does.

#5085052 UDP network layer must-haves?

Posted by hplus0603 on 11 August 2013 - 05:33 PM

If you really care about MTU, google "path MTU discovery" and check the "don't fragment" flag in the IP packet header.

#5084419 UDP network layer must-haves?

Posted by hplus0603 on 09 August 2013 - 09:56 AM

you are going to register your port, right?

You're kidding, right? If every custom protocol invented was registered, and ports not re-used, we would have ran out of ports in 1982. (Or earlier.)

And, given that you provide the server, and manage the server, how could another service be squatting on the same port? The only reason that could happen would be if some third-party user accidentally puts in the wrong hostname/port information in some other program. Or they did it maliciously -- this is known as a "fuzz attack."

It does make sense to include protocol version information in your preamble, though, so you can reject clients that are too old. This may not need to be part of every packet -- making it part of the initial credentials packet, and making successive packets just rely on successful authentication, might be good enough.

#5084418 Trouble understanding Enet tutorial

Posted by hplus0603 on 09 August 2013 - 09:53 AM

I think the best thing you could do is to build Enet from source, and just debug/step into the source (or grep for the functions you're calling and read the source.)


The best way to learn how to program, is to learn how to use 'grep -ri' :-)

#5084174 UDP network layer must-haves?

Posted by hplus0603 on 08 August 2013 - 11:01 AM

it can happen, even with TCP, The CRC only has so many bits

Although, luckily, pretty much all physical transport layers have their own detection/correction codes, that significantly improve the robustness. TCP over a 1/10000 reliable physical link would be terrible. Luckily, typical links have bit error rates much, much lower than that.

#5082668 rant/idea: alternative MORPG server model

Posted by hplus0603 on 02 August 2013 - 10:43 PM

Regarding renting servers, is this really a problem?


A half-gig RAM virtual server running Linux is $6/month at interserver.net. For RPG-style games, that should be enough.


A bare-metal server, capable of doing FPS-type gameplay, is about $99 at game server hosting companies like ServerBeach, and you can find cheaper options if you look around.


For development, Amazon ECC is great, because you pay by the hour, and if you need a few hours a week, it's really cheap. Always-on hosting is not as competitive in pricing, though.

#5082666 Game server DoS / DDoS mitigation strategies?

Posted by hplus0603 on 02 August 2013 - 10:36 PM

The ability to detect remote IPs that issue an unnormally high rate of requests, or an unnormal distribution of request types, is useful.


Also, hardening your system and setting in place upstream filtering is useful. If your ISP can throw away UDP traffic destined to you on ports that you don't care about, then your link doesn't need to worry about this. (The ability to do this varies based on the ISP and your relation to them, i e how good a customer you are.)


Making sure you have SYN cookies turned on on your servers and/or load balancers is common sense. Same thing for filtering obviously bad IP fragments, etc.


Regarding CloudFlare, they are a mid-tier DDoS vendor, worrying more about CDN than DDoS, so they don't have a lot of ability to work with custom protocols like games. I think you'd get the same from other CDNs like Akamai.

There are higher-end vendors, where you pay five figures a month plus possibly five figures per event to help mitigate attacks. Those vendors may be able to put in place custom filters that you and they develop together, and can target any services. Names that come to mind include Prolexic, Neustar, and Verisign. Some of those guys even claim that they started out specifically as DDoS mitigation providers for MMO games!


Another option is to run on a public cloud, such as Amazon ECC. Yes, you pay for bandwidth, but if the DDoS is some number of gigabits for a few hours, that's not actually going to accrue all that much traffic. On the other hand, on ECC, a determined attacker will be able to generate pretty big bandwidth bills for your service... and Amazon may find that your service disrupts other customers and cut you off if it gets bad enough.


Finally, you can get high-speed connections to your ISP, with a lower commit level. For example, you might be able to find an ISP that lets you commit to half a gigabit per second, yet allows 100 Gbps interconnect, and bills by the 95th percentile. You need to be under DDoS for almost two days, full time, to actually make the DDoS hit your 95th percentile. Given that renting out botnets is a lucrative market these days, somebody has to be really pissed at you to hit you with dozens or even a hundred gigabits for more than an hour. I've only really heard of that happening to the financial services people, presumably by black op teams from their competitors or extortionists.

#5082663 UDP network layer must-haves?

Posted by hplus0603 on 02 August 2013 - 10:26 PM

For metrics, you want various kind of parameters for gross trouble-shooting:

- customer class (if you have it)

- session state (not-established, negotiating, lobby, game, etc)

- size of packet

- number of payload messages per packet

- payload message types

- packet direction (to server or from server)

- number of dropped packets detected

- number of duplicate packets detected

- number of reordered packets detected

- measured round-trip latency

- number of malformed packets


In the best of worlds, you chuck all of this at some reporting infrastructure, and generate an online cube where you can slice your traffic across arbitrary dimensions (each of the things above classify packets across some dimension.) This doesn't necessarily need to be real-time, because it's useful for finding things you didn't know about your game. Each individual dimension could separately be real-time, and the drill-down would be relegated to a baked cube, for example.

At that point, you can get reports like "number of packets that are re-ordered, containing the 'fire weapon' payload."


Now, there's a second level of diagnosis, where you can get this data sliced, in real-time, based on specific identifiers. Specific IP. Specific game instance. Specific player. Random sampling. Etc. Being able to have a customer on the line and turn on tracing of that particular customer's traffic is super helpful while debugging.


Another useful feature is the ability to capture and play back traffic, both for analysis, and for actual system analysis. If you can capture all packets that go in since server start, then you can reproduce any server state offline for debugging!

#5081864 UDP protocol to minimize latency?

Posted by hplus0603 on 30 July 2013 - 10:47 PM

If you don't have some way to support reliable-in-order where it's really needed, then each dev will try to build it alone in each application system, which is a much worse place to put it than in the network layer proper.