Alternative to storing configuration in StreamingAssets?

[abusaenanos]

Hello!

By using the StreamingAssets folder to store the product information we are just exposing sensitive information to the public, and in a human-readable format like JSON.

Is there an alternative (i.e. hardcoding, passing it to EOSManager somehow) to this?

Thanks!

[nk-rakanishu]

We're also concerned about this, seems like a fairly big security hole.

[TheSLAP]

Difficult to move forward with this plugin as it stands currently. Another vote here to change how this is resolved.

[erasmus990]

Epic Games' Technical Account Management team has indicated that it is no issue for this information (I would imagine the EncryptionKey is an exception) to be available to users, provided that your Client Policy is configured correctly.

---

My open question to their Service Delivery team was as follows:

What is the sensitivity level of information like ClientId-ClientSecret (ClientCredentials), SandboxId, ProductId, EncryptionKey, etc. that would be used by Auth and Platform interfaces and so forth? I would like to use the official plugin recommended here: https://dev.epicgames.com/en-US/news/epic-online-services-releases-plugins-for-unity-and-unreal-engine , but the current implementation requires leaving all of this information exposed to users in both a JSON file and within its own logs. Is leaving all of this information exposed acceptable if we customize our Client Policy for the Game Client appropriately or use other mitigating measures? Or is there no reason to worry about this?

---

Their response clearly instructed that I should keep the ClientSecret under "lock and key", but was worded in such a way that I suspected might have been referring to the BPT or something else that could readily make use of ClientSecretEnvVar, so I rephrased my question:

My question was specific to the EOS plugin I linked above, which was: https://dev.epicgames.com/en-US/news/epic-online-services-releases-plugins-for-unity-and-unreal-engine

The instructions for which can be found here: https://github.com/PlayEveryWare/eos_plugin_for_unity

The plugin, as several github commenters have called out, leaves the ClientSecret (I think we are talking about the same thing here? https://dev.epicgames.com/docs/services/en-US/Glossary/index.html#D?term=ClientSecret ) exposed to the world in a JSON file, as well as the bulleted pieces of data below. Furthermore, as the plugin runs, all of the following data is logged into Unity's player.log file.

ProductName
ProductVersion
ProductID
SandboxID
DeploymentID
ClientSecret
ClientID
EncryptionKey

If you indeed advocate keeping ClientSecret under lock and key, and we are talking about the same thing, then I am very confused about Epic's recommendation about this plugin and its usage. I hope I am just missing something. I tried working around the plugin's need for this JSON file, but it proved to require an amount of effort (and possible future maintenance) that I do not believe is reasonable.

---

My question was then passed to one of their TAMs, and their response was:

It is expected that users will have access to the EOS Client ID and Client Secret (but not your BPT Client ID and Client Secret!) I recommend customizing the Client Policy with this in mind. Per the Client Credentials (https://dev.epicgames.com/docs/services/en-US/DevPortal/ClientCredentials/index.html) page, this should be handled as an untrusted client. Partners who need to ensure client security to perform certain operations will typically create separate trusted clients that they manage on their dedicated servers.

---

I am waiting on a follow-up clarification regarding the EncryptionKey. I hope this helps/reassures someone.

[Menyus777]

We're also concerned about this, seems like a fairly big security hole.

For untrusted clients this should not be a problem. The way you limit the untrusted clients authorities is via the client settings. (Remember EOS can be used by trusted BE services too, where indeed these information would be security sensitive. However, those shall be run in isolated environments anyway.)

[erasmus990]

Epic Games' Technical Account Management team has indicated that it is no issue for this information (I would imagine the EncryptionKey is an exception) to be available to users, provided that your Client Policy is configured correctly.

My open question to their Service Delivery team was as follows:

What is the sensitivity level of information like ClientId-ClientSecret (ClientCredentials), SandboxId, ProductId, EncryptionKey, etc. that would be used by Auth and Platform interfaces and so forth? I would like to use the official plugin recommended here: https://dev.epicgames.com/en-US/news/epic-online-services-releases-plugins-for-unity-and-unreal-engine , but the current implementation requires leaving all of this information exposed to users in both a JSON file and within its own logs. Is leaving all of this information exposed acceptable if we customize our Client Policy for the Game Client appropriately or use other mitigating measures? Or is there no reason to worry about this?

Their response clearly instructed that I should keep the ClientSecret under "lock and key", but was worded in such a way that I suspected might have been referring to the BPT or something else that could readily make use of ClientSecretEnvVar, so I rephrased my question:

My question was specific to the EOS plugin I linked above, which was: https://dev.epicgames.com/en-US/news/epic-online-services-releases-plugins-for-unity-and-unreal-engine
The instructions for which can be found here: https://github.com/PlayEveryWare/eos_plugin_for_unity
The plugin, as several github commenters have called out, leaves the ClientSecret (I think we are talking about the same thing here? https://dev.epicgames.com/docs/services/en-US/Glossary/index.html#D?term=ClientSecret ) exposed to the world in a JSON file, as well as the bulleted pieces of data below. Furthermore, as the plugin runs, all of the following data is logged into Unity's player.log file.

ProductName
ProductVersion
ProductID
SandboxID
DeploymentID
ClientSecret
ClientID
EncryptionKey

If you indeed advocate keeping ClientSecret under lock and key, and we are talking about the same thing, then I am very confused about Epic's recommendation about this plugin and its usage. I hope I am just missing something. I tried working around the plugin's need for this JSON file, but it proved to require an amount of effort (and possible future maintenance) that I do not believe is reasonable.

My question was then passed to one of their TAMs, and their response was:

It is expected that users will have access to the EOS Client ID and Client Secret (but not your BPT Client ID and Client Secret!) I recommend customizing the Client Policy with this in mind. Per the Client Credentials (https://dev.epicgames.com/docs/services/en-US/DevPortal/ClientCredentials/index.html) page, this should be handled as an untrusted client. Partners who need to ensure client security to perform certain operations will typically create separate trusted clients that they manage on their dedicated servers.

I am waiting on a follow-up clarification regarding the EncryptionKey. I hope this helps/reassures someone.

Their team's most recent response on the EncryptionKey being left exposed:

"As the Encryption Key is stored client-side, it is expected that players would be able to obtain its value even if steps were taken to obfuscate it. However, it is worth noting that the Encryption Key is not the sole component used in the encryption of data stored using the Player Data Storage feature."

[andrew-hirata-playeveryware]

Quick summary: Those keys are not as 'secret' as one might assume, and it's somewhat safe to have them in the open. They have to be in StreamAssets so that the GfxPluginNativeRender can access them before all of Unity has been bootstrapped so that the Plugin can hook all the appropriate things before the first graphics call by the Unity engine.