Another Security Thread

First things first: why are you trying to encrypt your traffic? 90% of the time when people ask how, it's because they're doing something that is ultimately a waste of their time, since they're often failing to consider more fragile and accessible breach points.

Using AES like that will not give you any security. Because it doesn't matter how you will store key in your application (ASCII or binary). If you will store key at all then anybody can retrieve key and decrypt your packets.

AES is very fast. On modern computer it can encrypt about 70MB/s and more.
AES key is usually generated as hash from some string (for example entered password). Or if key needs to be random, then its simply randomly generated. No special restrictions (except good random).

Quote:

Could you please tell me if the AES method is fast and short please ? Is Blowfish better, faster ?

The wikipedia page on Blowfish has some notes on speed compared to AES.

Quote:

Maybe I'm wrong, but can the AES key have any string length ?

My understanding is that AES is a number of ciphers which each work on a fixed key length.

Quote:

After that, I would like to know how to generate a random AES encryption key in C++, because I would like the server sends a random key to the player once that one has just connected.

How is the key exchange protected?

Quote:

If it's too hard to generate a random key, is it safe to store a unique key somewhere in the program ?

No, that isn't a good idea.

Quote:

I am trying to implement a way to encrypt my packets.

What kind of attacks are you trying to protect against?

Well guys, alright, I don't really know what to do just because I don't know really a lot of things about multiplayer safety and stuff...

Quote:

Original post by rip-off Quote: I am trying to implement a way to encrypt my packets. What kind of attacks are you trying to protect against?

I am making a 3D Chat, using ENet, and in other programs, when I use WinsockPacketEditor, I see some weird stuff like \...$!!~~...!....*...., and no string at all.

I am really afraid of people that could cheat by editing their packets so easily, like sending a fake name, speedhacking...

Then I would like to know the following :
- How can I make sure that the packet I send is not too big or too long to be received ?
- How can I tell the server to check if the packet is the same as it was made by the player ? (some kind of CRC32 check or I don't know, sent by the player somewhere in the packet).
- Or everything in one question : How can I check if the connected client is real and not a simple funny guy using Telnet or a simple VB App to connect via UDP to my server ?

Thanks for your help, I'm really getting confused and, I have a very big paranoia.

Quote:

Original post by Linaxys Could you please tell me if the AES method is fast and short please ? Is Blowfish better, faster ?

Whenever one encounters a question of "fast(er)", this is how to approach it.

There are many factors which affect "fast", and many of them aren't even code related. But writing a simple, repeatable benchmark, then letting it run real world examples is a very good start at getting a feel of how something behaves.

Quote:

sending a fake name, speedhacking...

By "sending a fake name", do you mean taking someone else's account? Having some kind of password system should stop this. You don't need encryption for passwords, a challenge response protocol where the server sends a nonce to the client, and the client responds with the hash of the password and nonce should work.

Speedhacking should be preventable by making the server authoritative and correctly programming it. It cannot be dealt with at the packet level.

Quote:

Then I would like to know the following : - How can I make sure that the packet I send is not too big or too long to be received ?

You could discover the path MTU size. Enet might handle this for you, or might allow you to specify your own upper limit over which it might automagically fragment packets.

Quote:

- How can I tell the server to check if the packet is the same as it was made by the player ? (some kind of CRC32 check or I don't know, sent by the player somewhere in the packet).

Yes, a CRC or hash will give you a check. This will only protect against accidental corruption, not malicious packet editing. Remember, UDP all ready does a minimal 16 bit checksum, which gives you limited protection against corruption anyway.

Quote:

- Or everything in one question : How can I check if the connected client is real and not a simple funny guy using Telnet or a simple VB App to connect via UDP to my server ?

You can't.

Hmmm, well, ok, I will try to use the nonce method...

I've never used a nonce, should I use it in every packets that need to be replied ?
I mean, this :



Well, I'm going to work more on my network part, I have realized that encryptiong should not be really necessary anyway, because it could be stupid that if someone break it, the game will look like having no encryption...

What would be a good solution to prevent someone flooding the server ?
I've heard something like storing a value like "getTime() + 20", if the user tries to send a packet in less than 20 ms after the last one, then it's ignored,...

How many milliseconds should I check ? 20 ms would be sufficient ?

Thanks you guys !

Quote:

I've never used a nonce, should I use it in every packets that need to be replied ?

No.

The purpose of the nonce is to prevent replay attacks on the password. The nonce is supposed to make sure that every time you login to the server you are sending a different value, but it can still be checked for validity.

---

There are a few different things happening in what I described. Here I will build up the protocol, giving reasons why each element is introduced.

Let us consider first the simplest protocol: send the password in plaintext.
Vulnerabilities: pretty obvious, the attacker can see the password and login as the user with very little effort.

Slight improvement: send the hash of the password.
Vulnerabilities: The attacker can no longer directly login as the client. They can however, store the packet the client sends and replay it to the server. So even though the attacker doesn't know the password, they still can get access.

Better again: send the hash of a password and a nonce. That is, hash(password concatenated with nonce).
Vulnerabilities: Very low chance that if an attacker records all the packets sent to a client they will ever get a chance to use a replay attack, as the server should be generating different nonces each time. Even if they do, this is a once-off opportunity to login, once logged out they must go through the same waiting process again.

---

The nonce should therefore have a wide range, not just a single byte with a value between 0 and 99. The idea is to ensure the chances of the server sending the same nonce to a given client is quite low over the lifetime of a password.

You may want to read my article on game authentication for some background information. You can find it in Game Programming Gems 7.

However, it sounds to me as if you're just trying to protect the wrong thing. The data in flight is almost never altered. The data is typically altered in the client, by injecting a new socket DLL, or by editing client memory directly. Thus, no matter how you encrypt data, the client should be assumed to be capable of cheating.

Thus, on your server, you should treat all data that comes in as possibly bad data, and you should code appropriately. If someone tries to bend the rules by sending a packet that changes the game state in a disallowed way (moving too fast, or whatever), either disconnect them, or just apply the rules and tell them what the real outcome of their action was, so they can correct their display. (Sometimes, those packets can be the result of different hardware, network delays, etc, and not cheating, so immediate disconnect is seldom the best strategy)

In short, it sounds like you don't need help with encryption, it sounds like you need help with designing enforcible game rules.

Just for fun [smile]

Quote:

Quote: - Or everything in one question : How can I check if the connected client is real and not a simple funny guy using Telnet or a simple VB App to connect via UDP to my server ? You can't.

One idea to combat clientless programs or altered clients is to implement functionality that is not used often that a hacker will easily miss when trying to replicate your client. That will usually only work a couple of times before it becomes ineffective. To keep it effective, you have to change up your client and make sure it's protected in ways that will discourage most people from bothering with it.

For example, let's say you have in a special packet that when sent to the client prompts the client to send back some predetermined value. If you occasionally send that out, any time you don't get a reply from a client within some time range, you can raise suspicions about that client. You just have to make sure the packet is sent as 'reliable'. I would suggest you simply keep an internal database of the number of times clients fail the check and on your weekly inspections, you look at the averages and if you see accounts that have 'outlier' results, you can ban them.

For other variations on that method, you can send a command that would read memory of the current process at some location that was being changed for a hack let's say. If the bytes match when you check on the server side, you flag that account for banning. You don't want to use ReadProcessMemory in this case since that would give away what you are doing, but there are assembly means of doing that as well. The caveat is, you will have to call VirtualProtect on some memory region, so that might be a dead give away, although you can use a larger range to make tracking it down harder.

I think detection is more powerful and efficient than simply trying to prevent people form cheating. Server sided logic is hard to defeat and you can rely on the fact that the client is always compromised. Additional server sided logistics can be helpful as well. If you took the time to add in special logic to track movements, average messages per minute, log messages with specific key words, you can actually create a decent security solution that helps combat cheaters.

If you play it cool for a while and let cheaters think they are doing something that you don't know, but you really know, you can wipe out a lot at a time and keep people guessing as to how they got caught and further deter people form trying, especially if accounts are not free or in limited supply. Of course, nothing here is fool proof, but these are things I'd be looking into to help protect my own game.

Quote:

especially if accounts are not free

No matter what approach you take, that is the main enforcing power you have. If you offer free accounts, there's really not much you can do on the enforcement side (other than IP bans and the like).

Quote:

Original post by Drew_Benton If you play it cool for a while and let cheaters think they are doing something that you don't know, but you really know, you can wipe out a lot at a time and keep people guessing as to how they got caught and further deter people form trying, especially if accounts are not free or in limited supply. Of course, nothing here is fool proof, but these are things I'd be looking into to help protect my own game.

Thank you guys, your answers helped me a lot.

Anyway, I've forgot that I am actually doing this application for Facebook.

I can recognize the users from their Profile User ID (an unique number).
Once logged in, my php script generates a random session key of letters and numbers, stores it inside the db in the same location of the facebook id, and it's the only thing used for the server to know if the user is real and logged in, the client sends it to the server, and the server gets every client's data from that key.

Does this make a lot of security issues ?
Or is it fully safe (I know that nothing is 100% safe... :p )

Thanks again !

You have to, at a minimum, protect agains cross site scripting attacks, and cookie theft attacks through HTML/&#106avascript injection.<br>Google for "prevent XSS" and spend a few hours reading...<br>