Its a lot harder than you think. With the game services exposed via a public port then I have a direct attack vector. I.e. the port. If I have to run everything through the proxy server then it will take longer, and you're more likely to notice.

Definitely, and we could keep adding different proxies between the entry point and the game to make it even harder to find an exploit.

I'm not saying that this is bad, just that the cost in development/architecture/latency has to be balanced against the gain for hacker to access the system.

Encrypted how? If i'm ON the server then I can read anything the SERVER can read. I can also poke around in memory and simply grab the decrypted keys, or even skip that and grab the decrypted configuration file.

Oh, the config is in plain text, but the particular value of the key needs to be decrypted to work. It's decrypted in memory of course, but since the key is simply a random value, you'd probably want to grab the java classes and reverse engineer those first in order to see where that's stored. Again, not impossible, but adds at least a day of work (for someone who's already reverse-engineered the entire protocol).

Since generating a new cert is trivial - it's then simply a matter of pushing out new clients - an attacker would need to work fast to put it to any use. Once a breach is discovered, changing cert + resetting passcodes removes any future gain for the attacker. Since the passcodes are just random numbers, the only permanent gain an attacker would have would be if they changed account data.

Again, for a different game this would be a much greater problem.

Washu

Thanks, that was a very interesting rundown of possible sploits (lots of material for a FAQ or good article there).

I'm still going to insist on saying that you are assuming a certain problem domain here. In particular a MMO in the style of EVE or WoW.

In my case:

- Players do not select (nor have any easy way to identify) the game instance/world

- Players' names are anonymized

- Players cannot exchange in-game currency with each other

- Each instance only holds about 100 player

- Accounts without user-selected passwords

- No real money transactions within the system

The only gain in breaching security would be cheating, and a single cheater is unlikely to cheat in more than a few worlds, affecting at the most a few hundred players.

What I do want to protect against is cheating that can be discovered and utilized by a large amount of players with little effort.

One of the strategies I have to combat that is that instead of - as is traditional - validate the command before performing it, I simply have checks built into every single game value which is validated every time they change. Failing a validation throws an error that rolls back any changes done during the execution of the command.

That way, instead of having to remember to check everything up front, I simply perform all actions and rely on that the objects themselves will throw errors when the player attempts something illegal. This ensures atomicity regardless of error type.

One thing of note however. Be sure that your product's architecture does not confuse certain legal user actions as DDoS attacks. We've had that where I work once where, in trying to mitigate severe DDoS against one of our products, we've also inadvertently gone too far and ended up disrupting service for some 'core users' whose actions per minute were well above established standards...

Well even if the results are personalized cloudflare has more ddos protection than 1 person with limited funding and limited time can do and caching could still be of use just not as much for the personalized results but things like some of the lobbys and player registration(until posted) could be and wouldnt have to touch your server at all. I run quite a few websites and trying to get into the gaming world on my spare time so my answers will definitly be web biased but running my own servers cloudflare has opened many doors that would have cost much more and much more time to handle on my own.

Cloudflare is awesome for web, but of limited use when you deal with plain sockets.

And like I mentioned it can handle the ssl so your server doesnt have to which is a major plus because you can quickly kill the server resources with multiple connections on a ddos and it would be much harder to take down a network like cloudflare.

Yeah, that's actually the reason for me having a dedicated login server. I brought my dev servers to their knees by selecting a naive RSA key size and reconnecting a few hundred bots in the span of a few seconds.

Now I have two stops in place:

1. Before the login server even looks begins doing any CPU intensive work, it gives you a puzzle challenge ("find a value, which, when hashed with this random value, produces a result with at least n trailing zeroes"). The better you answer, the higher priority in the login queue (and a incorrect result puts you last). A client which places outside of the queue has to request a new puzzle.

2. From the login server you get a ticket, which the game/login servers can open up with almost zero cost. This lets the server setup a secure channel without an asymmetric key exchange.

This allows me to minimize and constrain the CPU usage. Obviously, just using Cloudflare with SSL would be a whole lot simpler.

What kind of game are you making is it a mmo or something like fps? Some mmos work entirely over web traffic and some fps use ssl web traffic to login and get going like firefall they use aws.

It's an unconventional mmo, more like a multiplayer strategy mixed with rpg. Imagine, perhaps, a multiplayer "Pirates!" in a fantasy world. The most accurate description would be "Trade Wars" (the BBS door) played on a fantasy map/world.

In terms of responsiveness, I'm now seriously considering using UDP because I need low latency map movement (or the game will feel sluggish) and I have no real way to do anything predictive on the client side. A roundtrip in the vicinity of 100-200 ms on 3G is what I'm aiming for. This is nothing I would reliably get over HTTP or even TCP/IP due to the frequency of mobile wifi/3G packet drops.

If you have a set of game servers that are all exposed to the internet (port forward, just behind a firewall, on the DMZ, whatever). These servers, obviously, have to talk to the database. So clearly there's an open connection between them and the database. Even if the database is behind another firewall, on a different network segment, or any number of other network design decisions.

I just want to mention that I do think this is an interesting solution, but to be worth implementing for my particular game I would need to see some benefit beyond increased resistance against security breaches.

In my setup with login/lobby/game servers being hosted on different servers, I know that hosing the login server will not affect players already with a login ticket. Since such a ticket is valid 24h (depending on setting), a DDoS against the login servers would be easy to handle.

However, with the proxies, targets drop from 3 different to one single type (the proxy). In order to DDoS, it's now only necessary to hose the proxy.

In general DDoS needs to be handled at the network level. Normally I'd not worry about it as a programmer, and let my operations engineers / network providers worry about it.

A normal "flood" of too much traffic for your upstream bandwidth can be conducted by almost anyone with enough money. It is very difficult to defend against this using a "normal" unicast single-point-of-presence IPv4 routing scheme. This normally only affects "real money" games, i.e. gambling, who are heavily attacked for extorsion purposes. A flood attack doesn't even need to establish connections, they can just send random, spoofed-source TCP packets with otherwise valid port numbers, flags etc, so you can't block (all of) them with simple firewall rules upstream.

The "solution" normally involves using IPv4 "anycast", which can only be done by a peering company (i.e. one with an ASN and who uses BGP routing) - so if your own network operations team cannot do peering, then you need to partner with a network provider who can. A network provider will add some kind of proxy in front of your service, which will run on an Anycast IP address and forward "clean" traffic to your own backend servers over a VPN (or similar).

I can't imagine that any non-gambling amateur game would attract the kind of attention which would make someone want to do a DDoS attack.

A normal "flood" of too much traffic for your upstream bandwidth can be conducted by almost anyone with enough money. It is very difficult to defend against this using a "normal" unicast single-point-of-presence IPv4 routing scheme. This normally only affects "real money" games, i.e. gambling, who are heavily attacked for extorsion purposes. A flood attack doesn't even need to establish connections, they can just send random, spoofed-source TCP packets with otherwise valid port numbers, flags etc, so you can't block (all of) them with simple firewall rules upstream.

Mmmm yeah, I know of extortion attempts on several gaming sites and providers (casino and poker). For my service I'm not going to spend too much time on preventing DDoS, but obviously it needs to be able to survive a coordinated attack from a few computers (more of a DoS than DDoS scenario).

I hope to at least add fundamental countermeasures, creating a framework on which one could then build additional protection if it would be necessary at some time in the future.

I've dug deep into cryptography to design a protocol which I feel fairly confident in. Mostly because it's basically an implementation combining two well known protocols. Still, I know it's a risk.

No.

Don't do this.

Seriously, this is a bad idea.

Either use a well known cryptographic solution, which has been subject to peer review, or, if you are a cryptographer, and you see a need for a new approach, publish a paper on it, and if the paper holds up after a few years, then use it.

But rolling your own cryptography almost inevitably leads to a much much worse outcome than using something that has actually been subject to peer review.

Seriously, this is a bad idea.

Either use a well known cryptographic solution, which has been subject to peer review, or, if you are a cryptographer, and you see a need for a new approach, publish a paper on it, and if the paper holds up after a few years, then use it.

I'm wondering if you read what you quoted?

In particular, the login server uses a SIGMA-R implementation and the game/lobby servers uses a Kerberos-type ticket retrieved from the login server. So, except for potential errors in the implementations of these protocols, the weakness of the scheme should simply be that of the two protocols mentioned.

(The modifications I've made are: a) the standard SIGMA-R described uses two-way authentication, I only need to authenticate the server b) the login on the TGS (my login server) isn't using symmetric keys as in Kerberos standard, since user authentication isn't necessary)

Of course, there is also the selection of encryption/authentication/signature primitives. And here I've tried to follow NIST recommendations as far as possible.

Naturally, I've tried to get as much feedback as possible on my particular selections and reductions.

So, is this wholly safe? - No, that would be foolish to believe.

Is it a worthwhile trade-off for the flexibility it allows me, compared to the possible loss when someone breaks the protocol? - Yes, I think so in my particular case.