Mycal
Staff member
Warning, this is a long post and is mostly developer commentary. If you are interested in encryption, keep reading, otherwise just skip to the second to last paragraph (paragraph before the list at the bottom).
I've been working mainly on the login server side of things the past month after finishing the GUI changes (which, by the way, work fantasticly better than I had hoped). Currently, creating an account, login, and verification all work. In the interest of transparency, I'm going to outline the process here and why it's taken so long.
Everytime a game client is launched, before doing anything else, it creates a GUID that identifies the machine. This happens on each launch and rarely changes. It basically polls a few pieces of hardware and creates a GUID from the IDs/Serials they pass back. This is what we call the hardwareID, but more on this later. After generating this ID, the game then launches the main menu which, for now, consists of the login fields (username, password). When you click login, a JSON message is created containing your username and password. If this is the first message to the login server this session (or this launch of the game client), we initiate the connection with a hello JSON message. This message contains your last sessionID (which is generated randomly by the login server) and your hardwareID. The server replies with a message containing it's own public encryption key and your sessionID (whether it's the one you passed in or one that it generates is up to the login server's logic). From this point onwards, all messages are encrypted between the login server and the game server. I'll explain how below.
Basically, we use a hybrid system of encyrption. We use AES to encrypt all messages. The key used to encrypt the messages is generated by the client. The key that the login server sends back to the client is it's RSA public encryption key. This key is fairly useless on it's own. You can only encrypt with it as you need the private key to decrypt. The problem with RSA, however, is that it only works on small message sizes. It happens to work perfect for encrypting the AES encryption key. So the client uses the login server's public key to encrypt the AES encryption key. Then with the very next message, it sends this encrypted key with it's message. It is only sent once, as the login server can the store it with the user's session. Simple, elegant, and extremely secure. A hacker that intercepts any messages will now only know the user's hardwareID, sessionID, and the login server's public encryption key. That's it. They do not know your username, your e-mail, your password (which is stored using the bcrypt algorithm by the way), or any personally identifying information.
This is all done and functional, though I'm still working out a few bugs here and there. However, let's go one further. You are no longer logging into game server's directly, so how does the server know who you are? If you guessed username, you are wrong. The game sever's NEVER see your username, password, or e-mail. In fact, they know nothing more about you initially than a single unique GUID that you send them when you join. This GUID is generated on your login so it's never the same, but is always unique. The game server will then query the login server for more information about you. So far, all they get from the login server is an unchanging unique GUID, whether you have verified your account, and whether you are an Odyssey admin (currently only 1 exists). The server then uses only this piece of data to store game data for you. Your ingame name is chosen by you per server. So it is up to you whether you use your own username or not, but unless you physically tell someone, your username is known only to you.
This is as far as I've gotten with the login server, but there is still a lot I need to do and clean up. Somehow, I still need to incorporate private servers that do not go through the login server, but that will wait for another release. What I have left before I can move on is storing login information. I would rather not store a password in plain text locally on the user's machine, but I may have to if a user wants their information to be remembered. The problem here is, if we store it locally in plain text, it's easily visible to anyone who uses the computer or other software with access to the folder. If we encrypt the password, we have to store the encryption key somewhere so we are in the same boat. I could have it hardcoded, but since it's in C# it's extremely trivial to extract it. I could store the bcrypted password which means its not easily decrypted, but then the password textbox would not reflect the password length. So I'm not quite sure what to do about storing it locally. Perhaps I'll take a look at what other games do and go from there.
All in all, I should finish up the login server stuff by the end of the week. Actually, I absolutely have to have this working by the end of the week if I want to meet the release deadline in my head. I've got many things scheduled on my calendar and this one has already passed it's deadline by a week. I think I've said this before, but we're shooting for early 2013. I have a more narrowed date in my head, but don't want to disclose it out of fear of missing it. This has been an ambitious project, but it's fun and a lot of the hardest stuff is now out of the way. The vast majority of things left is simply conversion of game logic which should be fairly straight forward.
So task list of things before next dev blog:
I've been working mainly on the login server side of things the past month after finishing the GUI changes (which, by the way, work fantasticly better than I had hoped). Currently, creating an account, login, and verification all work. In the interest of transparency, I'm going to outline the process here and why it's taken so long.
Everytime a game client is launched, before doing anything else, it creates a GUID that identifies the machine. This happens on each launch and rarely changes. It basically polls a few pieces of hardware and creates a GUID from the IDs/Serials they pass back. This is what we call the hardwareID, but more on this later. After generating this ID, the game then launches the main menu which, for now, consists of the login fields (username, password). When you click login, a JSON message is created containing your username and password. If this is the first message to the login server this session (or this launch of the game client), we initiate the connection with a hello JSON message. This message contains your last sessionID (which is generated randomly by the login server) and your hardwareID. The server replies with a message containing it's own public encryption key and your sessionID (whether it's the one you passed in or one that it generates is up to the login server's logic). From this point onwards, all messages are encrypted between the login server and the game server. I'll explain how below.
Basically, we use a hybrid system of encyrption. We use AES to encrypt all messages. The key used to encrypt the messages is generated by the client. The key that the login server sends back to the client is it's RSA public encryption key. This key is fairly useless on it's own. You can only encrypt with it as you need the private key to decrypt. The problem with RSA, however, is that it only works on small message sizes. It happens to work perfect for encrypting the AES encryption key. So the client uses the login server's public key to encrypt the AES encryption key. Then with the very next message, it sends this encrypted key with it's message. It is only sent once, as the login server can the store it with the user's session. Simple, elegant, and extremely secure. A hacker that intercepts any messages will now only know the user's hardwareID, sessionID, and the login server's public encryption key. That's it. They do not know your username, your e-mail, your password (which is stored using the bcrypt algorithm by the way), or any personally identifying information.
This is all done and functional, though I'm still working out a few bugs here and there. However, let's go one further. You are no longer logging into game server's directly, so how does the server know who you are? If you guessed username, you are wrong. The game sever's NEVER see your username, password, or e-mail. In fact, they know nothing more about you initially than a single unique GUID that you send them when you join. This GUID is generated on your login so it's never the same, but is always unique. The game server will then query the login server for more information about you. So far, all they get from the login server is an unchanging unique GUID, whether you have verified your account, and whether you are an Odyssey admin (currently only 1 exists). The server then uses only this piece of data to store game data for you. Your ingame name is chosen by you per server. So it is up to you whether you use your own username or not, but unless you physically tell someone, your username is known only to you.
This is as far as I've gotten with the login server, but there is still a lot I need to do and clean up. Somehow, I still need to incorporate private servers that do not go through the login server, but that will wait for another release. What I have left before I can move on is storing login information. I would rather not store a password in plain text locally on the user's machine, but I may have to if a user wants their information to be remembered. The problem here is, if we store it locally in plain text, it's easily visible to anyone who uses the computer or other software with access to the folder. If we encrypt the password, we have to store the encryption key somewhere so we are in the same boat. I could have it hardcoded, but since it's in C# it's extremely trivial to extract it. I could store the bcrypted password which means its not easily decrypted, but then the password textbox would not reflect the password length. So I'm not quite sure what to do about storing it locally. Perhaps I'll take a look at what other games do and go from there.
All in all, I should finish up the login server stuff by the end of the week. Actually, I absolutely have to have this working by the end of the week if I want to meet the release deadline in my head. I've got many things scheduled on my calendar and this one has already passed it's deadline by a week. I think I've said this before, but we're shooting for early 2013. I have a more narrowed date in my head, but don't want to disclose it out of fear of missing it. This has been an ambitious project, but it's fun and a lot of the hardest stuff is now out of the way. The vast majority of things left is simply conversion of game logic which should be fairly straight forward.
So task list of things before next dev blog:
- Finish login server stuff
- Begin testing basic socket connections (this is a straight copy from the BSGame so it should just work)
- Begin converting game logic
- Begin work on the editor UIs (for what I have planned from the last blog post, this shouldn't be too difficult).
- Test, test, test!