Contents

Why we need it

To run leagues we need persistent authentication

To prevent abuse by repeat offenders

To prevent server admins from being able to get passwords

How authentication works now

We just have two passwords, one server password for creating a new company, and one for connecting to an existing company. Passwords are stored in memory on the server and sent in plaintext, in the clear.

Proposal

Client decides it wants to connect to a server. On beforehand, the server owner must have been given the client's public key.

Key verification (Handshake)

Because all necessary keys need to be present at all necessary places, this makes certain that all required mechanisms are in place before the actual authentication takes place. It also kicks out disallowed clients at an early stage.

Client connects to the server, and asks to be authenticated

Server asks client for its key fingerprint, client sends fingerprint

If this fingerprint is in the allowed list of clients, authentication proceeds

If this fingerprint is not in the allowed list of clients, authentication fails

Server sends client its key fingerprint, client checks if it already has this key

If client has matching key, proceed

If client does not have matching key, ask server for key, and download key from server

At this point, both server and client have each other's public keys, and authentication can take place.

Authentication

Server creates a random string/number/whatever (henceforth called 'random item'), and encrypts it using the client's public key. At the same time, it signs it using the server's private key, and then sends this off to the client.

Client verifies signature and decrypts the random item.

Client then encrypts it again, using the server's public key, and signs it using its own private key and sends it back to the server.

Server verifies signature and decrypts the random item. Server, having kept a copy of the random item from when it was created, compares the two, and if they match, authentication has succeeded.

NOTES

Username / password is not needed. The GPG key acts as the username, and the password authentication is done locally on a user's computer through the GPG program. GPG encryption is considered extremely secure, and the only way to pass off as another user would be to get a hold of both his private key and his password.

Because all communication both ways are encrypted and signed, putting up a man-in-the-middle attack is extremely cumbersome. Because the server owner is given the client's key on beforehand, the person attempting man-in-the-middle attack would actually have to disrupt this process first, which can be near-impossible, before even having a chance at the man-in-the-middle-attack in the first place.

This idea can be combined with the ideas in CentralisedAuthentication to be a stronger protection scheme. The idea presented here, however, can also be used without an external authentication system, and is thus also perfectly viable on hidden/LAN games.