Lacewing Game & Login Security

[mikecom]

I've been sporadically working on a basic shooter using Lacewing, and had a question about making this game as secure as possible to prevent cheating.

Currently, all the information in my game is client-to-client based. I've been playing around with it and trying various methods to secure this. Would I have to hash it, send it to the main server, have the server push that update to the rest of the clients, and have everyone decode their own message and properly update? Is this the most efficient way to handle this? Would there be added lag as opposed to just directly sending to the client?

I also plan on running my own server to handle login and registration, as well as some other server side specific features (i.e., leaderboards, stat tracking, etc.). What I'm currently setting up is a basic INI that is encrypted/MD5 hashed. Users will input their information, the client will hash it and send it to the server, and the server will respond with an Accept/Deny confirmation. What other measures should I take to ensure full security?

This is just intended for my friends, so it'll be a relatively small userbase, but I want to treat it like there will be hundreds of users, in case I ever decide to release it for Android or anything.

Thanks!

[tompa]

Interesting, I use a three part key for decryption. A local part, a server part and a user specific. Do I understand you correctly by assuming that you send a hash depending on user info that you compare to a register? Anyway it's possible to enforce sent data with AES or Blowfish in fusion.

Secondary a bruteforce protection can be applied to the server, I just restrict the same Ip from making x connections in y time.

Third, a simple algorithm used on both sides can act as a scrambler. The sent data will never be the same making it harder to find patterns if listening software should be applied. I won't tell you my algorithm but you could use something simple as adding 1 to the answer, it's still generating a whole new cipher block.

Bruce Schneier the creator of blowfish has a lot of interesting tips on his website https://www.schneier.com/
I'm very bad at times with explaining solutions in text, Bruce isn't.

I prefer using blowfish, as the method I use is less prone to error in MMF than when I'm using AES.. this is probably because my AES extension is old. On the bright side a blowfish block is shorter than an AES allowing less bandwidth being consumed. Note that even if the AES cipher is the most popular, several others including blowfish remains unbroken.

[mikecom]

Very interesting! So correct me if I'm mistaken, you encrypt the sent data to the server, the server adds a "scrambler" and pushes it back to the rest of the users, and the end users unscrambles and decrypts the data?

Also, aren't both the AESFusion objects and Blowfish extension outdated? I also need something compatible with the Android exporter, I plan on porting this over when the project has made a lot more progress.

[tompa]

I only do that when logging in but you could do that for other things, the overhead would be at client and server not on the bandwidth (depending on stack size).. there will be pretty much work if you chose to use encryption often, because it has to be efficient.

yes, exactly. my scrambler is a random element and an algorithm that both client/server knows, these consists of 3 bytes in my case. Depending on game version I change algorithm. I chose to force the user to use the latest client version (I want users to have the best version).



I see both ciphers are available in the extension manager now, I used an old AES from MMF2. The one in the manager might work better and it seem to be compatible with Pc, Android & Flash.

Further I've read that some games use a token system (ie minecraft) wiki.vg/Authentication but I don't currently have it myself, it seems to me that it's a server efficiency feature for having users connected.

There are even snippets available in java/c/go wiki.vg/Protocol_Encryption that may shine some light on the subject.