I am making a persistent online multi-player game and am currently looking at basic security. I have some questions after reading this:
This is where I'm at so far:
- By day I'm a .NET web developer and this project is all in C#.
- Main game communications happen over UDP, provided by lidgren.
- Lidgren provides per-message encryption options (Xtea, AES, DES, Triple DES, RC2...).
- I already have Awesomium integrated into my client to provide the user interface.
- A web service provides the back end for non-action related UI such as mail and trade. It always runs over HTTPS.
- The web server and game server share a SQL database.
- Passwords are salted, hashed (bcrypt), and stored in the database.
- I plan to also use the secure web service as the login server.
All that is reasonably straight forward and I've done most of it before. My questions are when I try and work through the 'sufficient implementation' provided in hplus' conclusion:
- Client connects to game server and transmits the auth ticket. Doesn't this already need to be encrypted to prevent against sniffing on open networks? But the server apparently doesn't retrieve the encryption key till later, so what is stopping someone else grabbing the ticket and connecting as you?
- Is there any reason not to start the sequence numbers at 0 given we already using a random encryption key?
- Aren't sequence numbers going to be fairly useless with UDP unreliable messages?
- What is a suitable hash for ongoing messages once authentication has been established? I assume this is really just a checksum to make sure the data hasn't been tempered with.
Also, would you still give the same advice today? Reading the archives here I get the feeling should really be looking at TCP/TLS instead, if at all possible...
Thanks for any help you can offer.
Edited by Sprangle, 07 September 2013 - 02:03 AM.