Hey everyone,

I'm using Electron, and since I have access to their net package (nodejs), I've been doing some P2P testing lately. I have an authorization server that handles all game logic. But, I wanted to switch to a P2P approach for only movement outside of PvP for testing. I know it's not ideal, but I'm just playing around with it for now.

Anyways, with that said:

Someone could easily get the IP of someone their connected to. Thus, let's say Player A is connected to Player B and are in a game together moving around, communicating fine.

Then, Player B logs off. Player A gets notified by this, by the authoritarian server.

But, there is one catch. Lets Player B sniffed Player A's IP address and then connected to them and just starting to send movement signals all over the place. (Without even being in a game).

Or dos/ddosing that user.

This basically opens up a huge can worms, right? Am I getting all of this right, or is there something I'm missing? :P Maybe create a UUID that expires, that is needed for two clients to connect? But then again, unless their firewall is modified they can still cause massive harm to that player? (Even with a firewall, UDP/etc can still do decent dmg)

Sorry I'm kind of all over the place here, I'm just curious do I have the right train of thought? (P2P = Hacking/Cheating/abuse is inevitable), 100%?

Thanks ~

> dos/ddosing that user.

Yes, it is possible. A centralized star architecture where players only know the address of the server does not necessarily expose the addresses of other players.

Attacks are possible from anyone on the public Internet, so that is nothing new. Anybody can attempt a denial of service attack on any IP address.

> Player B sniffed Player A's IP address and then connected to them and just starting to send movement signals all over the place. (Without even being in a game).

Not likely. Each connection is a 4-tuple of {source IP, source port, dest IP, dest port}. For connection-based systems when the game ends the connection will end too. Establishing a new connection will require a new handshake which you don't have. Your own game is going to have its own protocol and rules to follow, so being outside the game and influencing the game is not something they can do unless you build that in to your protocol.

It is possible for someone to introduce their own proxy and play the game through the proxy, then maliciously introduce additional commands while they are in the game. That is a standard attack vector. The solution there is to never trust anything coming over the wire, always validate all input, no exceptions.

> (P2P = Hacking/Cheating/abuse is inevitable), 100%?

There are attack vectors in all networked software. When the software is popular enough someone will want to attack it.

Defending against all possible attacks is not really possible. Figure out what the most realistic attacks are against your system. Then either design your system so the attacks do nothing, or write code that defends against those attacks. Don't worry about the rest.

Thanks Frob, hplus, and Norman. I upvoted your posts, but will respond just once to everything :P

However, rules enforcement, and outside-the-game shenanigans like DoS-ing, aren't under your control anymore

This really put the nail in the coffin for me.

I am definitely going to incorporate the token/key to each player before connecting. As hplus said, I guess anything further than that, is beyond the scope of what I can do. Which makes me feel sad because obviously I cannot do anything else, but happy because now I don't have to think about it anymore :)

Thanks guys so much, your information here is really invaluable. I cannot see me asking these types of questions on StackOverflow or whatnot without getting shot down so I appreciate it!

Encryption typically protects two people behaving well from having a bad actor inject stuff or usefully eavesdrop.

Encryption doesn't help if the person on either end is a bad actor. They can encrypt stuff that violates your protocol all they want and send it over the secure connection.

Think of encryption as an armored car service. If both sides of the transaction are behaving all is well. It doesn't matter how good the service is if the person sending the packet is the criminal sending a bomb or shorting you money; the service will securely transport the bomb or the insufficient funds. If either side is a bad actor then encryption doesn't help much.

So yes, encrypt your data for the good guys, so they can have secure transport and be secure from some attacks. But no, don't assume all data over an encrypted line is valid. Attackers can use encrypted connections, too. You still need to validate every byte that comes across the wire.