View source for Hash Based Authentication

This page is intended for fleshing out the details of a simple authentication scheme.

== Ingredients ==

* The code that is already there, see [[Authentication]].
* A hash function H() like MD5, taking arbitrary data as input and giving a fixed lenght output
* A (game) client
* A (game) server
* An authentication server

The authentication server holds a database of usernames and hash functions of their passwords.

=== Scrambling eggs === 
An important sub-recipe is the scambling eggs-protocol, which is designed to permit an entity P to prove to an entitiy V that it knows a shared secret d without enabling an eavesdropper C to convince V. It works as follows:

* V generates a random bitstring s (the salt) and sends it to P
* P computes h0=H(d+s) and sends it to V
* V accepts iff h0=H(d+s)

where H is a one-way function and + denotes string concatenation.

== On the Client ==

The client uses the existing feature of password based authentication:
* The server sends a password challenge, containing the username to authenticate and a random salt s generated on the server.
* The client retrieves the user's password (from the user or from storage in memory or the hard disk) p.
* The client calculates H(H(p)+s) and sends the result, together with the username, back to the server.

The real password, or anything useful to steal the user's identity, is not transmitted. If H() is a good trapdoor hash function, you can't reconstruct H(p) or even p even if you know s.

== Simple Case: Game Server = Authentication Server ==

When a user is to be authenticated, the server generates a random salt s and sends that with the username to the client. It waits for the response with the client's version of H(H(p)+s). The server fetches the real H(p) from the database, calculates H(H(p)+s) on its own and compares. On match, the user is authenticated.

== Game Server and Authentication Server are Separate ==

=== On the Authentication Server ===

The authentication server waits for connections from the game server. It reads a username to be authenticated from messages from the server, generates two random salts s1 and s2, fetches the hash of the user's password H(p) and calculates h1 = H(H(H(p)+s2)+s1). Yes, it scrambles the already scrambled password two more times. The result and the two salts are sent back to the server.

This communication is even more useless to intercept than the client-server communication, it's scrambled even more.

Another thing to note: the game server now does not have the possibility to use the authentication server's response to imposter the user on another server. The information is just good enough to verify the user's identity.

=== On the Game Server ===

When a user is to be authenticated, the server sends the username to the authentication server and waits for the response, consisting of h1, s1 and s2. It sends the username and s2 to the client as in the simple scheme, the client returns h2' = H(H(p')+s2) where p' is the password entered on the client. The server calculates h1' = H(h2'+s1) = H(H(H(p')+s2)+s1) and compares it with h1. If they match, p must be p' and the user is authenticated.

== Attack Vectors ==

=== The Phishing Server ===

I can't set up a server to permanently steal identities, but I can do the following:
* I set up an innocently looking server and have a client in the background
* I wait for a victim to connect
* I connect my client to some other server that uses authentication, logging in as the same user
* I wait for the password query
* I forward it verbatim to my victim, he enters his password
* I forward the data sent back by the victim verbatim to the other server
* I'm logged in as my victim. Mwahaha!

Countermeasure: The salt s2, as the client receives it from the game server, always gets the game server's IP and port appended to it before it is used for scrambling. The authentication server does the same. Then, the phishing server would need to be able to forge IP traffic and appear at the other game server's IP.

Alternative: Three way communication. The salt s2 is not actually used by the game server, it could be sent directly from the authentication server to the client. In the above attempt, the message would go to the phishing server instead and the victim's client would not even trigger the password dialog.

Both methods don't work with current clients.

=== Faking the Authentication Server ===

If someone can forge the authentication server's response to the game server, he obviously can get free entry into the game server as anyone he wants. Real cryptography could help here (we're not bound to the ingame network protocol here and could use ssl), but at least, the game server's message needs to also contain a randomly chosen token the authentication server's response has to mirror, or else the attacker can try to inject a forged response without being able to read the network traffic.