Security of customProperties

Options
Hi folks,

I'm using PUN+ and was wondering about the security of using customProperties. I see that using them is suggested in a lot of places, but if a player can change the properties of all other players wouldn't that be compromise the security of the information stored?

Basically any client can set any type of information I store there for any other client and it will update on all ends.

Would be great If anyone can clarify this.

Thanks ahead,
Michael Papkov.

Comments

  • JohnTube
    JohnTube ✭✭✭✭✭
    edited April 2017
    Options
    Hi @StarKist,

    Thank you for choosing Photon!

    You are raising a good point and your concerns are legit.

    First of all, you should enforce "security" in your app using:
    - Custom Authentication (allow only trusted clients)
    - Obfuscation (minimize risks by "hiding" custom properties string keys)

    I can suggest a workaround (did not test it but should work):
    The idea is to have one or more custom player properties that should be used to prevent updating properties of other players.

    - Initialize one or more custom player propties without broadcasting them (look for Broadcast parameter). This way only the player knows these properties.
    - Use CAS: everytime you want to update player properties, use the above properties as expectedProperties.
  • legend411
    Options
    JohnTube said:


    I can suggest a workaround (did not test it but should work):
    The idea is to have one or more custom player properties that should be used to prevent updating properties of other players.

    - Initialize one or more custom player propties without broadcasting them (look for Broadcast parameter). This way only the player knows these properties.
    - Use CAS: everytime you want to update player properties, use the above properties as expectedProperties.

    Hi @JohnTube , love the sound of this solution but I can't find anything in the docs about a "broadcast" parameter for SetCustomProperties... can you elaborate?

  • JohnTube
    JohnTube ✭✭✭✭✭
    Options
    Hi @legend411,

    You should look for references to ParameterCode.Broadcast.
    You should look for lines in "LoadBalancingPeer.cs" or "NetworkingPeer.cs":
    opParameters.Add(ParameterCode.Broadcast, true);

    The solution has one flaw though:

    If player Y joins after player X, player Y will receive all of player X's properties in the JoinRoom operation response.

    So you should set each secret player's properties only after all players have joined or renew the secret property after each new player join/rejoin.
  • legend411
    Options
    JohnTube said:

    Hi @legend411,

    You should look for references to ParameterCode.Broadcast.
    You should look for lines in "LoadBalancingPeer.cs" or "NetworkingPeer.cs":
    opParameters.Add(ParameterCode.Broadcast, true);

    The solution has one flaw though:

    If player Y joins after player X, player Y will receive all of player X's properties in the JoinRoom operation response.

    So you should set each secret player's properties only after all players have joined or renew the secret property after each new player join/rejoin.

    JohnTube said:

    Hi @legend411,

    You should look for references to ParameterCode.Broadcast.
    You should look for lines in "LoadBalancingPeer.cs" or "NetworkingPeer.cs":
    opParameters.Add(ParameterCode.Broadcast, true);

    The solution has one flaw though:

    If player Y joins after player X, player Y will receive all of player X's properties in the JoinRoom operation response.

    So you should set each secret player's properties only after all players have joined or renew the secret property after each new player join/rejoin.

    I see...

    I'm looking at LoadbalancingPeer but I don't really understand how I would use that parameter in my own call to SetCustomProperties(), this looks like I'd be mucking with some PUN core stuff?

  • JohnTube
    JohnTube ✭✭✭✭✭
    Options
    this looks like I'd be mucking with some PUN core stuff?
    Yes this is required unfortunately as the Broadcast parameter is not exposed at a high level since this use case is not common and we want to avoid complexity.