Authentication without a central authentication server

[IntegratedQuantum]

Design Goals

• Clients should not be able to impersonate other clients (and gain access to their character/inventory).
• Servers should not be able to silently relay the login process to gain a session on another server

Preliminaries

• Each player has a public/private key pair. Ideally these are presented to the user as a seed phrase, so we always have the option to switch seamlessly to a new algorithm in case the old algorithm got compromised.
• The protocol should use some form of encryption past the initial key exchange to avoid a man in the middle from tampering with the packets once the session is established

Login Process

• TLS initialization (without certificates)
• the server asks the client to sign the TLS packets in various key-pair configurations (to provide migration options)
• The client signs the TLS packets and sends the signatures and related public keys back to the server
• The server uses the public key of the preferred method to find the player they belong to
• If no player is found, the public keys of the old methods are used to look for player

Obsolete public key encryption proposal

• The client sends its public key to the server
• The servers uses the clients public key to encrypt a challenge, the encryption type and a key for the remaining encryption process.
• The client decrypts the message and sends the challenge data back to the server (using the now encrypted channel)
• The server decrypts the data and uses it to verify the client's ownership of the public key
• The server then uses the public key to look up the player data, if it doesn't exist yet it creates a new file

Limitations

• Without server certificates a man in the middle could still hook into your connection, however it would be impossible to do so without providing a different public key, so the original account is not under attack. Of course if an attacker were to do this over a long period of time, then they could take over your account eventually, but it seems unreasonable to do this in a block game, so I don't think we need to worry about it.

Old proposal

To my surprise it seems like this is actually possible

Design Goals

• The client should be able to log in with a single password and username(or another identifier, to be decided) to all servers
• A malicious server must not be able to steal your credentials

Registration

1. The client sends its username/id to the server
2. The server creates a new private/public key pair for the username/id and stores them in the player file.
3. The server sends the public key to the client
4. The client generates a new password for this particular server
5. The client stores its password alongside the server public key and encrypts them using the player's password
6. The client sends the encrypted password+public key back to the server
7. The server stores the encrypted password+public key in the player file
8. The client logs in using the method below

Login

1. The client sends its username/id to the server
2. The server looks up the encrypted password+public key using the username/id and sends it to the client
3. The client decrypts the per-server password and public key using the player's private password
4. The client now encrypts the per-server password with the server's public key, note that only the real server can decrypt the password.
5. The server decrypts the password computes a hash and compares it with the stored hash, if no hash is stored yet (because we are in the registration process) it stores it now.

Remaining problems

• The server knows the public, the per server password and knows the player-password encrypted version of these.
  Together this may be enough to brute-force the player's password.
  → A sufficiently secure encrpytion algorithms needs to be used to prevent this.
• If a malicious server relays this handshake to a target server, then it can steal your account for a session there.
  → A solution could be to send the IP the client connected to alongside the per server password in step 4. This would allow the server to identify if the client directly connected to it or chose an indirect path.
• If the world is shared with other players, then the per player private keys would be public. This would allow a malicious server to decrypt your per-server password, allowing them to join the original server.
  → It would make sense to store the private key somewhere separate from the world itself to still allow world downloads. Furthermore a mechanism to re-register a player on the world copy is needed.
• Anyone could create a new account under your username/id on a server and you wouldn't be able to claim it back
  → I don't think this is even solvable. It would be rather annoying to the player if this happens, but they could just change their name in that case.

Sources

I took some inspiration from http://www.peerson.net/papers/passwordsP2P.pdf

[Argmaster]

Anyone could create a new account under your username/id on a server and you wouldn't be able to claim it back
→ I don't think this is even solvable. It would be rather annoying to the player if this happens, but they could just change their name in that case.

This is an advantage and disadvantage at once. On one hand it means someone can claim your username (but you can always choose a different one), but on the other hand it means that you can't globally claim rare usernames and sell them. Additionally as practice shows usernames most likely to get stolen (streamers, internet celebrities) are also ones which are most likely to change their usernames often to NOT get recognized.

The problem I see is that they can't just change their username if they are playing with this one on different servers, or they will lose all their stuff, they even may run into more conflicts, which means they may claim even more names before they find one that is not used on any of the servers they play on. That sounds like a very bad cycle.

To solve the inconvenience part of the problem we could just add server list with username configurable on server basis with global username being the default.

However problem of claiming multiple usernames is much harder to solve, rather impossible without external authority like phone numbers or emails

[codemob-dev]

We could have display names separate from usernames, but that might be over complicating things.

[Argmaster]

Why does the public private key pair have to be per player?

[Argmaster]

We could have display names separate from usernames, but that might be over complicating things.

That unfortunately has some other implications. To avoid situations where players on the servers are pretending to be someone else then they are you would have to display both and this creates UI challenges both for chat and for user name labels. For PvP servers it's a difference between life and death.

[IntegratedQuantum]

Why does the public private key pair have to be per player?

It might not be strictly necessary, but if it is global then it could be brute-forced, allowing you to decrypt the per-server player password of every player, if you get access to the encrypted version. However if it's per player, then you cannot brute force it, since you only know it if you intercept the initial registration.

[Argmaster]

What if we used Sha 256 hashed nanosecond timestamps of when the game was first run as player names? Ofc we would communicate to the player "hey, it's your identity, save it or you will lose all your shit". Then we would display only first few hex digits, as many as necessary for it to be unique on that server (like git) + display name. Basically a tag. How hard is it to have same nanosecond timestamp or Sha 256 as someone else?
This is only for the display name problem ofc. If someone steals it it kind of sucks, but there is still password to cover your existing accounts.
It's just a tiny bit better than copying whole server list.

[IntegratedQuantum]

Actually I think we should just keep it at names. Sure renaming is a bit of a pain on servers you are already active on (you need to log on with both and swap over your inventory and fix up all the totem permissions), however I think this is better than using random ids since it easy to forget about them. Especially since it is kind of unusual for games to use a random id like this.

Furthermore if someone does steal your ID then it is rather difficult to change it and remember which one to use for which server.

It is much easier to remember names, and name variants, in the worst case you may just need to go through your aliases in order and try them all until one gets accepted by the server. Nowadays people do seem to have many names already, since on many platforms you cannot choose the one you like.

[Argmaster]

As we already discussed in discord, there is no way to change master password after it's set. Since the name is claimed you are no longer able to re-claim it. Sure, there are plenty of good practices regarding passwords which would reduce the likelihood of this problem, but the whole problem with passwords comes from the fact that people don't follow those guidelines.

What about clean installation/ hardware change? Will it be possible to re-claim your accounts only knowing your password?

[IntegratedQuantum]

What about clean installation/ hardware change? Will it be possible to re-claim your accounts only knowing your password?

Yes of course, that's why the server password is stored on the server.

[IntegratedQuantum]

The server knows the public, the per server password and knows the player-password encrypted version of these.
Together this may be enough to brute-force the player's password.

Maybe instead of hashing the player's server password we can use another private/public key pair, this would mean the server only knows the public keys (which could be encrypted again with the private key) and not the full contents of the encrypted data, and thus cannot perform a plaintext attack.