   Security talk
  So I was directed here to talk about some network security idea. I'm doing the whole hash the client password on the client side with a GUID and then sending that hash over to the server to validate the user. I'm also using a GUID as the session id tied to the IP address.So my idea is trying to stop clientless programs from sending rogue messages to my server. My idea is as follows and I'd be curious of what people think. Feel free to rip it apart.Game messages are basically enums (mine are anyway. I assume most do it this way). So the challenge is that a person with your client could do certain actions, sniff their packets, and then figure out the ID of all your messages and their parameters. Now they have all they need to create their own client to start sending their own messages. To remedy this I was thinking of having a dynamic message system. I convert my GUID to string, so what I would do is the server send the client a random number from 0-100. Both the client and server would store this number and the message of it being sent would be something not related to what it's really used for. The number would represent where in the GUID string the actual message integer ID would be placed. Then that would be done for all the messages and each would get their own hash value based on the GUID and the message id. Those would get tied to the actual message and the function that message calls on the client side, and the exact same on the server side (but the server side has a message map per user since each users would have their own GUID which would change the hash value). Then when a message is to be sent, a look up is done on this message map to find the hash value of this message. That hash value is what is sent to both client/server. since both client/server now have the same entries of hash values for the messages they know what each other are talking about. The GUID and the reassigning of the hash to message id could happen every min (in my turn based game anyway, since there isn't allot of network traffic), so it's always changing.So there would need to be 3 pieces of information someone would have to know in order to fake a message. The actual message id, which I suppose they may be able to sniff their memory and find, the hashing system, and the random number as to where the message id was placed inside the GUID before it was hashed. I guess I could also do some algorithm on that random number so once it gets to the client right before it desides where to place it, it can do the algorithm to change where it really goes. As long as the server knows what algorithm was used it could do the same thing and hash values could match.So thoughts? I really think this would be a cool system to stop people from sending game messages via their own client. So if someone had a packet sniffer on their system, that hacker would know that clients GUID, but since the message id's is ever changing they wouldn't be able to sent predefined messages on their behalf causing issues with that player.   
Quote:Original post by rpillerSo my idea is trying to stop clientless programs from sending rogue messages to my server.Unless the client is under your complete physical control, it cannot be done.Everything else is merely a deterrent, which you can push as high as the expected level of sophistication and determination of your users.Your idea is based around transient per-client state. This can be effectively implemented using per-field/per-message entropy encoding (arithmetic, Huffman, LZW), which means that for each session, the values sent over wire change. There can be several dictionaries per connection, perhaps even one per message field.This mechanism is fairly robust, but doesn't really add anything to security. As soon as user rips the codec routines from your own executable, or simply hooks them, they have completely bypassed the problem.Such methods prevent replay attacks, obfuscate the contents, can be naturally combined with compression and raise the bar of sophistication. But historically, as soon as hashing became too complex, client was disassembled, and related routines ripped and used directly. EQ packet sniffers did this (among others) and effectively won the arms race.   ;  That make sense. I guess as far as the clientless thing goes the server game logic is really key to make sure they can never do something that the normal client wouldn't allow them to do at any given point. ;Quote:Original post by rpillerThat make sense. I guess as far as the clientless thing goes the server game logic is really key to make sure they can never do something that the normal client wouldn't allow them to do at any given point.Third-party man in the middle attack is unlikely. It's simply too complex, and there are other considerably more effective methods to obtain relevant information. This type of attack is also somewhat simple to protect against, even SSL and related cryptographic methods can be used.So the realistic MITM will be end user, with valid client, inspecting its own traffic locally. At which point, whatever client can do, so can the attacker. Then it's only a matter of raising the bar, or simply solving the problem elsewhere (WoW's approach of trusted/untrusted code + third-party client inspection).   ;  If that's the case then does it even make sense to worry about changing message id's/session id's randomly throughout the session?I read stuff like http://bonkel.wordpress.com/2008/03/31/sniffing-world-of-warcraft/ and it seems this guy had a hard time figuring out the messages. Maybe he's not going about it the right way, but with his method of basic trial and error, I would think changing the message id's and session id's randomly would really help against his application knowing how to read/send messages from his client.Maybe that's one type of attack and there are probably other more advance attacks, but changing message id's and session id's randomly throughout the session (and I mean once every min) could really make things hard on memory readers and packet sniffers. Again, maybe I'm completely wrong. I'm wondering really if it would be worth it to implement this idea based on how it would be cracked and the amount of effort it would take to do so.   ;Quote:does it even make sense to worry about changing message id's/session id's randomly throughout the sessionNot really. However, if the server expects a certain message id, or a certain session id, then if it gets a message id it doesn't expect, or a session id it doesn't expect, then you can be pretty sure something's wrong with the connection, and you can drop it.Similarly, you have to tie sessions to IP address (and perhaps port); else a client could log in as one user, but then suddenly send a message saying he belonged to some other session, and cause some other player to trade away goods with himself, for example. You should verify the claimed session ID of the packet with the recorded IP/port address for that session, and if they mismatch, disconnect. Or simply just derive session is from the remote ip/port, rather than storing it in the packet at all.Regarding that sniffing guy, I doubt he's one of the more skilled in the business. The really good ones don't just publish what they're doing in their blogs, for a variety of reasons.   ;  Good about why doing it can help. I just finished my logon code and I do tie this session id with the username and ip address of the person who requested it originally. If things don't match up the logon is not allowed. So I think I have a good first step. Now to implement the every changing message id's. I'm open to any tips you guys have about security.Quote:but then suddenly send a message saying he belonged to some other session, and cause some other player to trade away goods with himself,I think the good thing about my game is that this isn't even allowed. It's kind of like an RPG chess turn based game. There is no trading or anything allowed. Really I will need to focus on not allowing to buy items when they don't have the money, or prevent cheating in the chess game.   ;Quote:Original post by rpillerIt's kind of like an RPG chess turn based game. Why not just use TCP and slap some SSL on it if you wish to be fancy.Quote:it seems this guy had a hard time figuring out the messages. Maybe he's not going about it the right way, but with his method of basic trial and errorThere's 3 ways to serialize data in C++: memcpy to POD, virtual (member) functions and hard-coded functions (can be templated). The later ones will be dispatched via some switch statement, some container or function pointer/virtual function. Each of these results in different code, but each of them isolates the data (un)packing process in executable.  And there's only a very small and finite number of possibilities. Rather than guessing opaque bytes from packets, it's simpler to just go ask someone who knows the layouts, namely the executable itself.It's also noteworthy that it wasn't the technical measures that stopped this particular guy, but good old-fashioned lawsuits.Most frequently, effectiveness of security is not determined by finesse, but simply by using a bigger stick.   ;Quote:Why not just use TCP and slap some SSL on it if you wish to be fancy.I'm not sure what you mean here. It's a 3D game written in C++. I'm using RakNet in UDP mode, but I'll be using RELIABLE ORDERED.It's also an MMO type game where the armies are persistent. The armies have levels and gear/abilities that they buy etc.[Edited by - rpiller on April 27, 2009 1:21:32 AM];Quote:I'm using RakNet in UDP mode, but I'll be using RELIABLE ORDERED.His suggestion is that you instead use a straight TCP connection, or use an SSL connection (the security layer used by secure web servers in HTTPS).   