gameauth (at) mindcontrol.org
Authentication for games where untrusted clients connect to one
or more trusted servers is an interesting special case of general
authentication. This article presents some alternatives that can
go into designing authentication for such as system, and proposes
one particular set of internally cohesive design choices.
- 2010-12-21: Updated description about hashed passwords,
adding section on rainbow tables and hashing functions.
Authentication is the process of making sure that someone says who
they say they are. For computer games, this comes in two flavors:
Note that Authentication, the ability to determine who sent a specific
message, does not have much to do with Encryption, the ability to hide a
message from unintended recipients, except one kind of cryptosystem
(public/private key systems) have the ability to provide both functions
in one go. Unfortunately, these cryptosystems are usually very computationally
expensive, so they're not a great match for real-time, online services
like computer games.
- Game login
given a user name and password, match the information against a
database of allowed players.
- Game sessions
given a network packet, make sure that it's sent by the logged in
player it says it came from.
2. Game Login
To secure game login, you need to worry about a few kinds of problems:
- Insecure passwords
Players may have a password that's a common word (like "secret"),
the player name itself, or even blank. Your password setting mechanism
should detect weak passwords and require a better password. The bare
minimum is six characters or more, with at least one letter, and at
least one non-letter character.
- Insecure password storage
Are your servers secure? Someone might break into them. If they can
read the password in clear text, well, that's a problem. Also, are the
operators of your system trustworthy? Even after you just let them
know that their services will no longer be needed? It's safer to store
passwords in a way that means you can't easily read them back.
- Sniffed passwords
If you don't use Secure Sockets or some similar encrypted protocol,
it's possible that someone can use a packet sniffer to read a password
sent in clear text, and then impersonate the user in question.
- Multiple logins
The same user shouldn't be allowed to be logged in more than once, or
what will happen is that a single player will pay for the game, and
share the log-in with all his friends. While this is a small bit of
lost revenue, the bigger problem comes when you have to ban the account
because some of those "friends" didn't play by the rules. This is a
customer service nightmare.
Let's examine security in your client/server design a little closer:|
The main trade-off you have to make is whether you want the
passwords to be recoverable from the database or not. Depending on this
choice, you have the following two options:
- Recoverable passwords
If the password is recoverable, then you can use the
Challenge Hash Authentication scheme.
This is a major benefit. However, the passwords are
more vulnerable when they are recoverable in the database.
Don't store the passwords in cleartext in the database. At least scramble
them using some key that you build into the code, to make it harder for
the casual inspector to "accidentally" see the password. There's still a
danger that the passwords can be compromised, so be vigilant against
human factors that can compromise your data.
- One-way hash passwords
When setting a password, you calculate a one-way hash of the password
(such as a SHA-256 checksum), and store the checksum. When the user tries to
log in the next time, he gives you a password, and you calculate a SHA-256
checksum of that, and compare to the stored checksum. If they match, you
assume the password was correct.
The main benefit here is security on the system side; reading an SHA-256
checksum will not immediately let anyone know what the actual password is.
Finding another password that generates the same checksum is computationally
very hard. However, you must use Secret Exchange
Also, when using hashed password storage, common passwords like "password"
or "123456" will be easily found, for example using a rainbow table. Even
less common, but short, passwords can be brute-forced. One defense against
this kind of attack is to "salt" the hashed value with some data that
changes per entry, so that two entries storing the same password don't have
the same hashed value. However, anyone recovering the salt will still be
able to recover the password using guessing, unless you have a way of
making the salt a lot harder to come by than the password database. This
weakness means that you might just decide to store passwords recoverable
in the first place, and implement good security practices to avoid leaking
the password database in the first place.
2.1. Challenge Hash Authentication
In Challenge Hash Authentication, the server issues some random number,
called a "challenge", to the client. The client computes a hash of this
random number and the client-side entered password, and sends the hash
value back to the server. The server then computes a hash of the remembered
challenge value and the stored (plain-text) password, and compares to what
the client submitted. If the hashes match, the right password was supplied.
There are three main properties of this system:
- Passwords are not transmitted
Thus, someone sniffing the regular login traffic will not be able to
determine what the password is.
- The challenge is specific to each login attempt
Thus, if you sniff the connection, you cannot remember what the hash is
and then just re-supply the same hash value later to log in, because the
random challenge generated by the server for a specific login attempt
will be different than the last.
- The server has the clear-text password
This is a security problem if the server side becomes compromised, but
the clear-text password, which is a secret shared by both sides of the
communication, can be used to encrypt any data coming to/from that
particular client. Care has to be taken to use an encryption algorithm
from which the key cannot be recovered, of course -- XOR would not be
2.2. Secret Exchange Authentication
In Secret Exchange Authentication, the server stores a hash of the password.
The client submits a plaintext password, and the server hashes this plaintext
password, and compares the hash to the stored hash. If they match, the right
password was supplied.
There is one strength and two weaknesses in this system:
- The server doesn't store the plain-text password
If someone breaks in and steals the password file, it doesn't matter,
because you can't guess what a password is just by knowing its cryptographic
strength hash. On old UNIX machines, the strength of the cryptography is
not that high, so you should still keep your /etc/shadow file secure, but
with a 256 bit SHA-256 hash, you should be pretty safe. If you can't trust your
backup operators, or if you get hacked, then this is a major benefit!
- The password is transmitted on each login attempt
If someone can sniff the connection, they could recover the password. Thus,
you have to secure the login attempt using some kind of encryption -- but
it's not clear what you should use as a key to achieve good security. The
most secure way involves a Diffie-Hellman key exchange, which is fairly
tricky code to implement right, but will provide for a secure, encrypted
channel between two endpoints, without prior exchange of keys. If you
wanted to protect against a sophisticated attacker inserting themselves
in the middle of the network, you would additionally have to introduce a
public key based cryptographic authentification system, but computer games
by and large do not have to worry about this kind of attack.
- The server has the clear-text password
Because the client sends the clear-text password, the server has at least
temporary access to the clear-text password, and can use this as a key for
future communication encryption, after the initial log-in. Unfortunately,
this means that if someone can impersonate your server, or read the memory
of your server process, they can still recover plain-text passwords, even
if the password storage file itself is secure.
3. Game Sessions
Once the player has logged in, your troubles are not over. You often need
to transfer a player from one machine to another, or to allow the player
to disconnect from the server (perhaps through crashing) and then re-
connect, resuming where he left off. You clearly can't just let the client
say whom it is, and have the server blindly trust that, because it would
be trivial for another player to suddenly impersonate another player.
Instead, you have to use one of three techniques:
Identity by IP Address,
Identity by Autentication Token or
Identity by Cryptography.
3.1. Identity by IP Address
In this method, the server looks at the source IP address and port
number of the arriving packet, and internally have a table that tells
you which player sends on which address/port pair. This is secure, as
long as you know that the player will keep sending from the same port,
and as long as you trust that the internet will not accept spoofed
addresses in packets -- or, if a packet is spoofed, that some round-trip
confirmation with the real client can take place.
Such round-trip confirmation can come in the form of explicit
acknowledge of particularly suspect commands ("surrender game" for
example), or implicitly by using a rotating sequence number starting
from a negotiated, random initial starting point.
Sadly, if you use TCP for your connections, or if you need to hand
connections off between servers, then the port part of the client's
address will not necessarily stay the same. TCP allocates a new port for
each connection for each machine it connects to, and even UDP can suffer
port renumbering when you switch destination machines, if it's behind a
non-friendly NAT gateway (although most home NAT routers don't impose
3.2. Idenfity by Authentication Token
When the player logs in, the server determines a duration for which the
connection is good; for example, one hour. The server then calculates a
hash of a few pieces of data: the client ID, the expiration time of the
login session, and a secret number that only the servers know. The server
then sends a token to the client, which contains the client ID, the
expiration time, and the hash of the three pieces of data.
When the client sends data, it precedes the data with this token. The
server picks apart the identity, time, and hash parts, and re-computes
the hash with its internal secret number. If the hash matches the hash
in the supplied token, the server knows that the packet comes from the
player who initially authenticated with the server (barring any sniffing
or man-in-the-middle attacks throughout the session).
If the client crashes and then re-connects, it could read the cookie from
disk and re-supply it, and as long as the session is still valid, it
would be fine. If game sessions last more than an hour, the server that
the player is currently talking to would extend the cookie by half an
hour each time the cookie is at least half an hour old by re-generating
a new token based on client ID, new expiration time, and a hash of those
entities and the server secret number. That way, a client can crash and
then keep playing as long as it re-connects within half an hour, without
having to log in again.
3.3. Identity by Cryptography
If you use a shared secret between the server and the client, such as a
plain-text password, then you can use that secret as key. Each packet
sent by the client contains the client ID in plaintext, followed by the
packet data, encrypted by the shared secret, followed by a checksum of
the (unencrypted) data.
When the server receives a packet, it looks up the client password in an
internal table, decrypts the message, and verifies the checksum. If the
checksum doesn't match, then the data was not encrypted with the right
password, and thus the packet did not come from the right client.
Best practice says that part of the encrypted data should be a sequence
number, so that successive identical packets will still encrypt
differently, and so that capturing and re-playing a packet will have
a low likelyhood of being accepted for real.
If you are reading this, it's a good sign -- you care about security, and
want to do it right!
A good encryption algorithm to use when both sides know the key (such
as when using Secret Exchange authentication
and Identity by Cryptography identification)
is the Tiny Encryption Algorithm, which
is easy to implement, yet cryptographically strong. However, if you can
find an already-implemented library implementing the current standard
encryption algorithm (AES), it's usually better to use that. For C++, a
good encryption library is the crypto++ library, available from SourceForge.
SHA-256 is a commonly used hashing (digest) function, and is currently considered
secure. However, to deny a brute force attack, you may want to use a library like
bcrypt, with a high load factor. Just make sure to scale your sign-on servers to
keep up with the added load.
A sufficient implementation of authentification and identity for a
cluster of collaborating trusted servers (such as for an MMORPG) would
look something like this:
If you are using TCP for your transport layer, you might want to use
a SSL/TLS library instead, which solves the Diffie-Hellman and session
key encryption problem, but you still have to implement a ticketing
solution of some sort.
- As setup, all servers in the cluster share a large random
number, known as the cluster
- Client connects to login server.
- Using Diffie-Hellman key exchange, client and server negotiates
keys for login.
- The server issues a challenge to the client, consisting of a
128 bit random number.
- Client calculates a hash of this number concatenated with the
password the user enters, and supplies the hash to the server.
- Server verifies that the hash of the challenge and stored
password matches what the client supplied, and issues an
authentication ticket consisting of user id, ticket expiration
time, and hash of a cluster secret combined with these two items,
and supplies to the client. This ticket may also contain the IP address of
the client (part of the has as well, in that case).
- Login server also generates a random key for use by this
client during this sessions, and supplies to the client. It also
records the key for the user, and the expiry time of the ticket.
- Client connects to arbitrary server that is part of the game
- Client starts connection by sending authentication ticket.
- The new server verifies that the ticket has not expired, and that
the hash is correct. Using the user id in the ticket, the new server
retrieves the encryption key for the user from the login server.
- The new server and the client also negotiate sequence numbers for
future communications at this point.
- Once authenticated, the new server and client exchange data
encrypted with the session key, where the encrypted data includes
a hash of the data proper, and a sequence number. Each of these
packets only need to have the client ID and ticket identifier (a small
integer) as header, not the full authentication cookie.
- Periodically, the server that the client is currently connected
to checks whether the session authentication ticket is about to
expire; if this is the case, re-contact login server to get a new
ticket and forward it to the client.
This scheme will protect against the dangers of someone sniffing your
passwords on the open internet, and against the dangers of someone
trying to use a technical flaw to impersonate another player. However,
it will still not protect against the danger of a sophisticated
man-in-the-middle attack, for which you would have to add public-key
certificates. This technique also does not protect against a user
looking at all the data sent to his client -- he controls the machine
running the client, so he could always inspect the data in memory, so
your game design has to be cheat-proof, or provide incentives for
users not to cheat to get around that problem.
Recent reports from independent studies show that the newer voting
machines replacing old punch-card machines do not actually follow even
these simple practices; if you follow them, your game has a chance of
being more secure than the process that selects the next leader of the
free world. Whether this is a good thing or not is up to you to decide.
(*)Cluster shared secrets are also known as cluster keys.
Cluster keys can periodically change while the cluster
stays up, for extra security against compromise. The idea is to keep
a "current key" and a "next key", with a time at which the next key
becomes the current key. Tickets issued with an expiry time at or
after the roll-over time use the "next key"; tickets issued with an
expiry time before that use the "current key". When validating tickets,
the correct key for the expiry time supplied in the ticket should be
used. If the key rotation time is less than or equal to the maximum
ticket expiry time, then you also need to keep one or more "old" cluster
keys to be able to validate tickets that have not yet expired. However,
rolling over cluster keys every two hours, in a system with a one-hour
session ticket expiry time, should be quite secure enough for most