Online game: A fast not-so-secure cryptographic hashing / a checksum function in JavaScript?

Question

I don't need it to be too secure. Even md5, which is generally broken, is safer than what I need (as long as a collision cannot be found within 2 minutes, it should be 100% fine).

I need it for a videogame we'll be making in a hackathon this weekend. We have a server which will simulate the core parts of the game and we need to synchronize the several players (we're using socket.io and nodejs as comet server) and make sure no player is cheating by modifying values. Thus the checksum (if they send a valid checksum, which will compare to the one generated in the server, the user has the right stuff).

So, as long as the checksum is not too easily reverse engineered, it should be fine.

Also, since I don't have much experience with online games (I have used sockets for some time in C, Java, Python and even PHP, though), it would be awesome if someone could recommend some readings on general patterns followed. All I found was a paper explaining why Age of Empires 2's online kinda sucked :)

Thanks a lot

More ellaboration:

Every client has variables (objects with properties and etc.). Events happen at the client and thus states change. Depending on the states, the variables change. So, the client sends the states and a hash of the variables to the server. The server takes the new states from the client (which could be, for example, "right arrow is pressed"), checks if they are valid and then generates new values on the variables. Checks if the hash corresponds to the one sent by the client. If it doesn't, it sends a synchronization message to the client, giving him new values to it's variables. Then saves it all and sends updates to the other clients on the shared variables. (since not all variables can be seen by other clients)

The hashing is mostly for synchronization. I don't know if it's the best method, but it's what came to mind. However, I don't want a prick messing with the values if they are just a simply checksum (CRC32 for example) and not something more difficult to fake. That way I feel like synchronization will be easier.

Again, I don't have experience with networking on videogames, but from other stuff I've done, this sounded logical. I appreciate all feedback.

Answer 1

Don't trust the client. Use the server as a central authority, not for core parts but for all parts . Replicate as much of the game state as you can server side, and feed the clients that data. Don't do any processing/as little as possible client side. No matter what values the clients modify the server will reject them.

Answer 2

This way of approach I would not suggest. If any encryption is made at client side, it is not secure. I would suggest approach, to make an all possible action list , that is stored and generated on server. While player does any action, the changes are made to possible action list . When player browser sends you any action data, it is checked against possible action list , like permissions table, if action is allowed, then validate with regex, other input data. If you are interested in securing data flow, then use SSL. The last thing, would be using a public/private key encryption for data flow.

Answer 3

If you're generating the hash from the action on the client then it doesn't matter how cryptographically secure the algorithm is - its always possible that the client can manipulate the values and generate a new, valid hash. They don't need to reverse engineer the method used for creating the validation token - you've already provided the code for them to generate a bogus token.

That only leaves the option of generating a set of validation tokens on the server, sending them out to the client and allowing the client to return the relevant one - if you're doing that, then there is no net benefit in using a hash compared with symmetric encryption or even a random value.

Answer 4

Too many thoughts for a comment, so posting an answer that is as much more questions;

It's difficult to tell exactly what you are trying to protect here. If all you want is message sync... are you free to use TCP, and just let the protocol handle that? If that's what you planned to do, then I am completely at a loss as to what your question is.

If not, but you can't use TCP, then it may be more important to sync the messages than you think, especially over a LAN environment; you use the term 'hackathon', but I have no clue what that really means... but are you actually looking at preventing malicious/mischievous actions by other players, who might send spoofed packets? (extremely trivial to do over a LAN if UDP is being used)

If that's the case, you have to consider more than just getting a 'secure' method to assure sync; you also need to validate the source of all messages before doing anything with them, because the IP 'source' info in UDP/IP is almost worthless, aside from knowing where to send a reply. You can't assume anything based on the source IP.

(What I mean here is that due to the 'connection'-based nature of TCP/IP as opposed to the isolated datagrams of UDP/IP; UDP makes it easy in a closed environment such as you describe to send mischievous datagrams that could wreak havoc.)

If that's what you need, you are generally barking up the right tree; You want something fast, and just 'secure enough' to prevent quick analysis; the data is of a kind that you don't care if someone can look over it for an hour and figure out what buttons someone was pressing at any given moment - you just want to prevent someone from sending fake or DOS packets that are spoofed.

So each client/server connection should have a shared, random salt that should, at minimum, be regenerated each 'session'. Hashing takes place, and messages are sent with the hashed 'signature' - the message hashed with the salt. When the receiver gets that message/signature, it takes the message and does the same hashing with the salt, and its result must match the signature sent, or the message is spoofed.