I'm creating an online game and I was thinking about a way to handle login and was wondering if the following has any major issues that anyone could see.

1. Have a launcher app (node.js) point to a webpage that shows news about the game. On launch it also returns the latest client version from the server and the launcher app then checks the clients version on disk (since it's node.js it has these rights). If different then download the new client files.

2. This would also have a login form on the page. A user would log into this site. The site would then validate id/pw and give a guid session id and add it to the games database under that client as kind of an access token and return that token to the client. Maybe also returns the game server to connect to?

3. After login is validated the launcher app would shell out to the actual game exe passing the token, the username (and game server address) as a command line argument.

4. The game exe connects to the game server using my network library (RakNet in this case) and sends the access token & username which is checked in the database to see if any record matches both those values in the users table. If it does then the game exe can now play the game. If it doesn't the game exe disconnects and doesn't allow the player to play the game.

I've never seen the launcher app be the login for the game. That's usually done in the game itself, but is there anything wrong with having the launcher app being the login process for the game and getting an "access token" to pass to the game exe? Everything has it's flaws but is there any major security issues that wouldn't exist with any type of login system anyway with this way of doing it?

It's been done. It is also done for debugging purposes, as a way to launch with special keys or whatnot.

Yes, it exposes your login token, but chances are good that is exposed inside your communications flow anyway to anyone with a packet inspector.

Are you thinking this would run on Windows?

"Because it's node.js it has these permissions" -- not generally. Program Files generally always needs administrator permissions to write.

The proper way to handle patching on Windows is one of two ways:

1) Use the Windows Installer, and ship new versions as .msi installers. The user patches themselves, and elevate privileges when running the installer to update.

2) Put only two things in Program Files: The patcher, and a public key certificate. The patcher shows a splash screen, and asks the server for updates. If there are updates, download them, and then verify the signature of the update, then run it. The actual data lives in a subdirectory of %AppData%. Also, if there is no update, the patcher verifies the signature of the installed data in %AppData% before chaining to the application. This way, no malicious program can patch your game behind the user's back. (The user can still patch and start the game manually -- this is about preventing malware vectors.)

On Linux, you'll have to do something similar, because /usr/local/bin or similar locations are unlikely to be directly writable by the user.

Also, the "login token" requires each server to verify it with a central database. A perhaps simpler method is to create a token that consists of (timestamp:userid:remote-ip) and HMAC it with a (server-secret). Then issue the token as (timestamp:userid:remote-ip:signature). The client app then provides this back to the actual game server. The game server re-calculates the signature using the known (server-secret) and verifies with the provided (signature). That way, the game server can check that the token is not too old (or from the future) using timestamp, can check the user ID, and can check that the token is used from the IP address it was issued to, without having to connect back to a central database.

"Because it's node.js it has these permissions" -- not generally. Program Files generally always needs administrator permissions to write.

I'm confused with this statement. Not because of the facts is has but because you quoted something and I was looking for me saying that in the post but I didn't. I didn't imply Program Files anywhere either so I'm confused in the context you made this sentence according to my post. I do get the idea though about #2, which is probably the way I would go.

Interesting on the login token. I guess I just assumed all my game servers would have access to the central users database but this is something I'll look into, thank you.

That's what I read from this:

the launcher app then checks the clients version on disk (since it's node.js it has these rights).

I also assume that you mentioned node.js and rights, because you were considering local disk access, which for example web browsers don't have.

However, I do have to infer a lot by reading between the lines, because you haven't described anything about how you're developing the game, what the game is, what the distribution target is, what platforms you support, how you install it, or anything else that would make it easier for us to answer questions without reading your mind :-)

I guess I just assumed all my game servers would have access to the central users database

Yes, they do! But that's not the point. Do you want to pay for that database to be hit by every game server for every request from every player?

I've never seen the launcher app be the login for the game.

Eve Online.