Template:en/Obsolete

A proposal for authentication using GNU Privacy Guard inspired by Centralised authentication, put forth by Dphoenix

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

1. 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.
2. 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.

Centralised authentication

This idea can be combined with the ideas in Centralised authentication 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.