Authentication logic revisited

[Lucifer]

I think I've managed to work out the logic needed for authentication, keeping backwards compatibility, and so forth. Haven't looked at the code (I'm currently still reading rendering code, sorry)

Ok, first we assume that a separate password field will be transmitted by new clients.

We have several depths of authentication available. The purpose is to keep unique names on a server, so nobody could impersonate anybody else. (That's the main thing I'm concerned with)

1. Unique name during a game session
2. Unique name for all game sessions, even those you don't play in

Older clients won't transmit a password field, so the server would take their IP address as their password and only allow them a unique name during their game session. Since IP addresses change too much, there's really no other way I'm coming up with for a global unique name.

The server administrator would have several choices of configuration.

1. No authentication (password field is ignored)
2. Unique names only during game session (all clients are treated like older clients that don't transmit a password field)
3. Maximum compatibility, but allow global unique names (new clients will be able to secure their name for a period of time)
4. Only allow new clients for global unique names (older clients will be told to upgrade before logging in)
5. Registration only (so their name has to be in the password database already, presumably from an external source like a website)

The way the server accesses the authentication table should be like a plugin, so it would ship with a default plugin that uses its own backend. I, or someone else, could write a plugin to use a MySQL database instead (which would allow me to integrate authentication with the breakfast website).

Stat files? No solution, really, yet. Maybe the name field of the stat file could also contain an ID on the password table rather than the player's name?

Additional considerations:

1. This doesn't handle people joining under one name and then changing their name in impersonation.
2. It might be feasible to have the server issue a third identifier for a user&pass pair, so the user could change their username and still retain the stats from their old name, but still relinquish the old name so other people could use it if they wanted.

This post might just be a summary of previous conversations on the matter. (I don't think it is, but I'm feeling pretty under-the-weather right now and not thinking with the same level of fogginess I usually have)

[Z-Man]

( Reminder: the code for the password entering and transfer stuff is already there. All that's missing is storage of the passwords on the server. )

How about something like the ICQ-System? Every user gets a unique number on the server, only that number is used in score files and databases. Additionally, a database of the ID that used a nick last is kept; it can be used to identify and mark likely impostors by changing the nick to, say, Lucifer[2].
I notice I'm probably using the term database horribly, horribly wrong here and will never get a consulting job. Oh well. You'll probably want to keep ID, last used nicks and password in one single database.
With this scheme, users can rename freely without disturbing scoring.
Drawback: since the nick is basically meaningless, any form of global score server would have a very difficult time.

And I have to add, of course, my ceterum censeo: without connection encryption, password/ID/nick-stealing will be a piece of cake. Especially with automatic registration, because then the feeble password only "encryption" can't work. You need to get the password to the server at least once in clear text.

[Lucifer]

I'm not in any way opposed to using SSL encryption over a standard TCP/IP connection for authentication. There's no need for UDP in this situation, and there's plenty of libraries available to make this a trivial exercise.

Here's how I've done this same thing in a web application:

1. Connect the login to a SSL server for authentication.
2. SSL server authenticates, generates a random token for the session.
3. Random token is sent to the client (stored in a cookie with an expiration that equals the length of an HTTP session, so 20 minutes)
4. The rest of the "secure" page is served over regular http (no data served that's private, so no issue, only the authentication *needed* to be encrypted)
5. Client sends token to server with each request, server updates the expiration on the cookie.
6. Server uses the token to verify that the user has been authenticated.

So the user credentials never get passed in cleartext. But there is the danger of the token being snatched and used, since that is sent in cleartext.

In aa, the token generated for the session looks like it's just the players netID (I forget what you've called it in the past) and you've already dealt with forged IDs here, so only the method of authentication needs to be addressed.

Now, how to get there from here? Seems like we'd just do it the insecure way, knowing that even insecure it's better than what we've got, and have a plan for encrypting the login routine later on. Perhaps the next version after the initial introduction of authentication would use a TCP/IP connection for authentication, even if it's still unencrypted, and then the following version would introduce encryption. (maybe a lot of this is already there? I don't know, like I said, I'm looking at rendering code right now )

[Z-Man]

Sounds like a good concept.

So the user credentials never get passed in cleartext. But there is the danger of the token being snatched and used, since that is sent in cleartext.

Couldn't this be sovled by sending a checksum over the real message and the token instead? A snatched message could then only be repeated, but not used to craft new messages.

Now, how to get there from here? Seems like we'd just do it the insecure way, knowing that even insecure it's better than what we've got, and have a plan for encrypting the login routine later on.

I'm not so sure that a weak authentication is better than none at all. Now, everyone knows you can fake player names. True, we can't have a real competitive league right now, but implementing half-assed security is worse than none at all. At least now, when someone steals your nick, you can steal it back

Perhaps the next version after the initial introduction of authentication would use a TCP/IP connection for authentication, even if it's still unencrypted, and then the following version would introduce encryption.

I'd go all the way in one step; SSL is not that much more complicated than pure TCP, and AA has no support for TCP sockets and IO currently. We'd have to support the intermediate TCP only version for some while, and the traditional UDP login ( there's already two code paths, luckily only differing slightly ), and the final SSL login.

(maybe a lot of this is already there? I don't know, like I said, I'm looking at rendering code right now )

No, the amount of unused code lying around in AA is finite

[Lucifer]

Sounds like a good concept.

So the user credentials never get passed in cleartext. But there is the danger of the token being snatched and used, since that is sent in cleartext.

Couldn't this be sovled by sending a checksum over the real message and the token instead? A snatched message could then only be repeated, but not used to craft new messages.

Um, sure. I don't know that this is even possible in a web application which is probably the reason it never occured to me.

I'm not so sure that a weak authentication is better than none at all. Now, everyone knows you can fake player names. True, we can't have a real competitive league right now, but implementing half-assed security is worse than none at all. At least now, when someone steals your nick, you can steal it back

I think we can safely disagree here without butting heads. That is, unless I decide to start hacking on this myself, but I'm trusting to your superior knowledge of socket programming (because I have none, I've only ever used external libraries where all I had to do was give it some text and a place to send it).

I'd go all the way in one step; SSL is not that much more complicated than pure TCP, and AA has no support for TCP sockets and IO currently. We'd have to support the intermediate TCP only version for some while, and the traditional UDP login ( there's already two code paths, luckily only differing slightly ), and the final SSL login.

I can go along with that. I'm one of those rare programmers that actually likes to factor code, and I've fairly gotten the hang of abstracting interfaces to where you can change the underlying mechanics in any arbitrary fashion without breaking things. Maybe when I've either finished or given up with the rendering code I'll look at how I can break--er, effect positive change to the login code. Provided someone doesn't beat me to it (the likeliest possibility).