question on security
Options
Hello all! My name is Ed and I just have a few questions about the security of the photon socket server.
1.) how secure is the server when it comes to sending and receiving packets? how does the server decide if the packet it receives is coming from your application? I don't want just anybody using unity to be able to request data from the server .
2.)what if a hacker uses a superclass to force your client to send correct packets with their own data. for example send a packet that is used to perform some sort of action in game without actually performing that action required to send the request.
just a few questions if anybody can answer these thank, you very much
1.) how secure is the server when it comes to sending and receiving packets? how does the server decide if the packet it receives is coming from your application? I don't want just anybody using unity to be able to request data from the server .
2.)what if a hacker uses a superclass to force your client to send correct packets with their own data. for example send a packet that is used to perform some sort of action in game without actually performing that action required to send the request.
just a few questions if anybody can answer these thank, you very much
0
Comments
-
Pikker wrote:1.) how secure is the server when it comes to sending and receiving packets? how does the server decide if the packet it receives is coming from your application? I don't want just anybody using unity to be able to request data from the server .Pikker wrote:2.)what if a hacker uses a superclass to force your client to send correct packets with their own data. for example send a packet that is used to perform some sort of action in game without actually performing that action required to send the request.
This is what photon is made for: To enable you to write your own server business logic with .NET C# on top of a powerful socket server.0 -
So maybe a system that works just like the encryption built into photon with public and private keys?0
-
Encryption is supported by Photon, so you can send and receive data encrypted.
In Photon v3, you just call EstablishEncryption() (or similar) and wait for the state-callback that tells you when encryption is available.
Boris was just talking about an authentication operation, which compares incoming username+password to anything you saved in your database. This is "business" logic, which depends on your usecase and which Photon makes easy to implement.0 -
Thats already done, my client will not switch from the logon screen to the realm selection screen unless it received an authentication event from otherwise it will send a response stating credentials are incorrect. I was just wondering if there was already a built in private public key system that works like the encryption used to do(i understand that encryption is much simpler now as i am already using it for encrypting login details :P)0
-
I don't think so.
But implementing RSA is trivial, thats a 1 day thing even if you have to readup on it0 -
No, you can't access the shared keys or anything encryption-related. But I don't understand why you would need a "private public key system"?
Once encryption with the server is established, you can encrypt operations "on the fly" by just setting a bool flag for it. You don't have to care about the details.0 -
I have a question to clarify this - is Photon able internally to recognise its Peers?
I mean, for example John connects to the game, I check his login and password, and then I mark him as "trustworthy" peer and he can access the server.
Is it possible for someone else to "hijack" that peers session and to communicate with the server pretending he is John?
If that is the case, we need to manually implement some session validation mechanism, like passing session Id with each request.0 -
It's impossible to get into a encrypted conversation, except when you impose a server for the real clients and forward the communication to the real server as fake-client.
The shared key for encryption is only known for the two sides and can't be derived by observing the "exchange conversation" of client and server. Only public parts are exchanged.0