User Authentication

[JoWie]

One of the problems in subspace is user authentication. A server can very easily steal passwords. This is also one of the reasons for the exclusiveness of SSC.

 

An other online game solves it as follows:

 

When it comes to authentication there are 3 parties:

• Game Server, the zone
  
• Game Client, the player
  
• Authentication server
  

 

There is only one authentication server, but there are many game servers and clients.

Users can register at the authentication server by a web frontend and in-game.

The authentication server should never perform banning or anything related, this is up to the zones / billing servers. Also no scores, cross zone chat, etc.

 

Login procedure

• Client connects to authentication server. Sends its username and password. When successful the authentication server sends a random token back
  
• Client connects to the zone, sends its username + random token
  
• Zone connects to the authentication server, asks for verification with the username + random token. The authentication server removes the random token
  
• Client can now play in the zone
  

The random token is only valid for a few minutes.

Preferably the authentication server uses TLS for its connections.

Passwords are stored using SHA-2 hash + salt

 

 

 

This method allows every zone to use the same player database without the risks of password stealing.

[Hakaku]

Login procedure

• Client connects to authentication server. Sends its username and password. When successful the authentication server sends a random token back
  
• Client connects to the zone, sends its username + random token
  
• Zone connects to the authentication server, asks for verification with the username + random token. The authentication server removes the random token
  
• Client can now play in the zone
  

I disagree with this since you're basically granting another SSC monopoly. The client should be connecting to the zone first, then requesting the appropriate authentication server information for validation. As a zone owner, I want to be able to have the freedom to choose the authentication server I want to, just as I choose the biller. If your authserver ever happens to get hacked, I would appreciate a way to opt out of its service.

[Dr Brain]

One of the problems in subspace is user authentication. A server can very easily steal passwords. This is also one of the reasons for the exclusiveness of SSC.

 

An other online game solves it as follows:

 

When it comes to authentication there are 3 parties:

• Game Server, the zone
  
• Game Client, the player
  
• Authentication server
  

 

There is only one authentication server, but there are many game servers and clients.

Users can register at the authentication server by a web frontend and in-game.

The authentication server should never perform banning or anything related, this is up to the zones / billing servers. Also no scores, cross zone chat, etc.

 

Login procedure

• Client connects to authentication server. Sends its username and password. When successful the authentication server sends a random token back
  
• Client connects to the zone, sends its username + random token
  
• Zone connects to the authentication server, asks for verification with the username + random token. The authentication server removes the random token
  
• Client can now play in the zone
  

The random token is only valid for a few minutes.

Preferably the authentication server uses TLS for its connections.

Passwords are stored using SHA-2 hash + salt

 

 

 

This method allows every zone to use the same player database without the risks of password stealing.

 

While your scenario does work, it does have a few drawbacks:

Every player can connect to the auth server. This presents a great target for DDoS attacks. Also, neither server is authenticated as part of the process.

 

This is the technique I've had in my mind for a few months:

• Player sends auth request to game server, including a username and random public key X.
  
• Game server forwards request to billing/auth server.
  
• Auth server generates reply containing X and a random token Y, and encrypts BOTH with the auth server's private key, and sends it back to the game server.
  
• Game server forwards reply to player.
  
• Player decrypts X and Y using the auth server's public key (presumably supplied as part of the client).
  
• If X is unchanged, the auth server is assumed to be the true one.
  
• Player generates hash(password), then generates hash(hash(password)+Y) and sends it to the game server.
  
• Game server forwards hash to auth server.
  
• Auth server has a copy of hash(password) used in web registration process. It uses this and Y to generate a copy of the received hash. If they match, player is authentic.
  
• Auth server tells game server to permit player to enter.
  

 

To facilitate further secure transactions between the player and the billing/auth server, the following can be done:

• A symmetric key K can be generated. K is encrypted by the auth server using its private key, then encrypted again using X. This is forwarded to the game server.
  
• The game server forwards the mess to the player
  
• The player decrypts using its private key. The player then decrypts the result using the auth server's public key. The resulting K can only have come from the auth server, and cannot have been read by anyone else.
  
• Key K is used for all further communication between the player and biller/auth server.
  

 

While the game server is not directly authenticated as part of this, it is assumed that the auth server would not be connected to a rogue server. Either way, no password information is divulged to the server as part of the process.

 

The server has two possible attacks using this setup: It can prematurely disconnect the player from the auth/biller. It can also fail to notify the auth/biller when the player disconnects. Neither attack can do long term damage, as the server cannot spoof communication from either party. The worst I can see is some kind of ?usage exploit. That could be mitigated by a keepalive ping originating from the auth/biller once or twice an hour.

[JoWie]

My reasoning for not authenticating servers is so that anyone can set up a server and use it, without fear for name clashes. Since the directory server already has to resolve this, it might be undesired that it is done at two places. Unless ofcourse the Authentication server and directory server become the same service.

 

The possibility for DDoS is a concern, however it can be lessened a lot by the protections that are already in current billing servers. (the infamous "You tried to login to many times" message).

 

The connection to the authentication server can be trusted due to TLS (aka what https uses).

 

 

If you let servers choose the authentication server, nothing changes. Simply direct the client to a rogue auth server. To prevent the SSC monopoly, the auth server should never be able to ban players.

A zone can choose not to use the auth server however.

Also, everything is opensource, so nothing will stop you from setting up your own auth server + custom client.

[Dr Brain]

The possibility for DDoS is a concern, however it can be lessened a lot by the protections that are already in current billing servers. (the infamous "You tried to login to many times" message).

 

That really won't protect against a DDoS, since the server still has to process the incoming data. By funneling the requests through the server, DDoS attacks are limited to single zones, and not the entire network.

 

If you let servers choose the authentication server, nothing changes. Simply direct the client to a rogue auth server.

 

That's why the authentication server's public key needed to be supplied to the client beforehand.

 

To prevent the SSC monopoly, the auth server should never be able to ban players.

 

A single billing system (distributed, preferably) isn't intrinsically monopolistic.

[★ doc flabby]

I made a post a while back describing my approach to user authentication i think. I even implemented an authentication server. It worked something like this. (The design changed alot from what was originally posted)

 

http://www.ssforum.net/index.php?showtopic=19133

 

- Clients have Biller public key.

- When clients login, they encrypt their username/password/etc with biller public key.

- This is given to the zone. The zone forwards it on to the biller.

- The biller decrypts the information with its private key, and tells the zone if the player is allowed to connect.

- The zone then decides to let the person connect to the zone or not (local decision)

- i had the idea of separating the chat services from the billing services

 

 

The only way this could be abused is by hacking the biller.

 

A monopolistic biller is actually the BEST solution, provided that anyone can replace the monopoly is needed. We don't want to have to remember different usernames/passwords for zones.

 

And this option means you could run your own biller, and install your own key in the client.

Thus leaving the system open, should the main biller collapse, another one could take its place.

Edited November 26, 2009 by doc flabby

[L.C.]

Thus leaving the system open, should the main biller collapse, another one could take its place.

Could run the biller as a service and perhaps somehow configure a whole redundancy solution so that is ServerA goes down, it immediately switches to ServerB, then ServerC, etcetera.