We are witnessing the biggest revolution in games since the introduction of home computers: online games, played via modem over the Internet. Many companies now insist that every game they develop must have an online component. The most ambitious online games are persistent worlds, which immerse hundreds of players in a single, shared environment. Traditionally, game programmers have faced well-known challenges, such as artificial intelligence, fast 3D graphics, and input devices. In the development of persistent worlds, there is an entirely new set of problems.
Consider the following:
It seems that the introduction of every new game is followed by the introduction of web sites dedicated to cheating the game. In one- or two-person games, cheating is a minor issue, since it only affects one or two people at a time. However, a single cheater in an online game can affect thousands of people and have lasting implications.
Of all the issues the online-game developer must be concerned with, security might initially seem like a trivial problem. However, it is central to keeping a system running. A design error in the communication scheme or graphics engine might lead to suboptimal performance, whereas a design error in the game's security is the first step to ruin. In a scenario where customers pay for continued access to the game, letting hackers run free is a sure way to lose a large part of a paying customer base.
Consider the following scenario in a persistent online game. Ben is an avid player of the game, and one day he shows it to his friend Alyssa, who is a computer science undergraduate student. Out of curiosity, Alyssa writes a program to examine all network traffic generated by the game. To further her knowledge, she extends the program to randomly modify pieces of some of the messages the client sends. Unbeknownst to her, the server contains a bug that accidentally incorporates some of this random data into the persistent world and corrupts its database. About a week later, without warning, the server crashes, and the system administrators are forced to rewind the database to the previous week's state. Outraged, thousands of customers cancel their accounts, and the game dies a violent death. Given the damage that a simply curious programmer could cause, imagine what a hacker bent on revenge might do to exploit the smallest security hole.
In this article, we identify areas where security has historically been a problem, and where a client/server system is typically weakest. Figure 1 shows several ways a hacker can attack a game system. We also suggest defensive mechanisms for the most common attacks, and we describe what can happen when hackers get through.
Lest you think that security is just a theoretical problem, consider recent events in some popular games. It appears that Blizzard's Battle.net service contains some major security flaws at the outset. As any experienced DIABLO player on Battle.net will tell you, people have found ways to gather incredibly powerful equipment without earning it. Someone even went so far as to hack the game so that characters in a multiplayer game can be stolen right over the network. In QUAKE, hackers have created automated programs called bots that can automatically destroy opponents. These are free game networks; imagine the amount of effort hackers would exert to attack a pay-by-the-hour system, or if someone offered a Ferrari as a prize in an unregulated QUAKE tournament.
During the development of MERIDIAN 59, we received a shocking reminder of how dedicated hackers can be. At the start of the game, a player can customize a character by assigning numerical values to certain attributes. After the player selects the values, the numbers are sent to the server. Unfortunately, at one point we changed the selection method without changing the check in the server that ensured that the values were legal. Naturally, someone soon modified the client executable to send outrageously large attribute values, and they shared this hack with their friends. Soon we had godlike characters wandering around the world. Our first fix added the values together and checked that the total was under the legal limit. Within a week, someone had found that certain attribute values, when added together, caused the sum to overflow back into the legal range, allowing them to resume cheating. The lesson is that hackers can be extremely clever and persistent, so the lazy solution of security through obscurity is generally not enough.
It's not always the players who are to blame for security problems. MERIDIAN 59 has an administration mode, accessible only by game administrators, that gives complete control over the server. However, during our beta test, a careless administrator learning the system made some poorly considered modifications to the game world. The effects didn't show up until hours later, when suddenly characters' names started disappearing, and monsters began popping up in their inventories (they even attacked the players who were holding them!). We were forced to restore the game state from an hours-old backup. In a commercial system, this would have been quite disasterous. To avoid careless mistakes like this, you should be as restrictive as possible when handing out administrative powers.
Persistent World Architecture
Most persistent worlds share the same basic architectural features. To play the game, a user either installs client software from a CD-ROM or downloads it from the Internet. The client software contains code that communicates with the game server using a custom protocol designed for the particular game. Large static data, such as graphic files, sounds, music, and level layout are typically part of the initial installation onto the client.
The peer-to-peer approach used for most LAN-based games does not scale well to large-scale persistent worlds. When the game lasts longer than a single session, it becomes difficult to deal with players dropping in and out of the game arbitrarily. Performance also becomes a problem, since the amount of game state increases linearly with the number of players, while the amount of network bandwidth remains constant. A simple networked game, such as a shooter, has very little game state - perhaps as little as the coordinates of all the players and monsters, their weapons, and their ammo. This allows each game client to know the entire game state, and makes it possible to transfer to everyone else all the game states changes made by one client.
To solve the problems of a large-scale game, on the other hand, one or more game servers are set up in a central location to keep track of the game state. Each of the game clients communicates its changes exclusively to a game server, which communicates those changes only to the clients that need to receive them (Figure 2). For example, if one user moves his or her character, the server only needs to tell other clients in the user's vicinity. This reduces the bandwidth use of the game to an amount that will not overload users' modem-based connections.
Some virtual worlds last many years after their initial creation. This is one of the benefits of creating a persistent world instead of a transient game. To extend the life of a persistent world, developers often grow the game over time, by adding more areas to the world and new features to the game play. To support this, the client software must have a way to upgrade itself, preferably without any user intervention. This is one of the most important parts of the initial release of any persistent world, because although the world may initially be quite primitive, it has the potential to be improved dramatically over time.
Besides the game servers, there are likely other processes required to make the whole system work in a commercial environment. User account information might be stored in an external database, dynamic game updates might use FTP servers, and automatic mailings could require an SMTP server. These processes could run on the same machine as the game, but for performance reasons, they usually run on separate machines.
There are two security goals in an online game:
Protecting sensitive information is mostly a matter of configuring the server complex correctly. Each machine connected with the game, such as any web, FTP, or database server, needs to be secured. All game servers should be behind a firewall that only allows data through the ports that the game needs to operate. Finally, the server complex should be located in a locked area, since physical access to the machines circumvents all other security precautions.
As you can tell from our previous example with MERIDIAN 59, some amount of internal security is also necessary to prevent employees outside the development staff from damaging the game or leaking information. In general, administrative powers should be given out strictly to those staff members who require those powers to do their jobs. Once you grant power, it is almost impossible to take it away, so be extremely sparing. Limit serious power, especially the ability to change account information, to a few trusted, on-site individuals.