The cache file for the remote config is not encrypted. This means we literally can not use the remote config cache in our games due to possible cheating.
So : Does Unity ever plan on encrypting this file?
And also, has anyone fixed this issue somehow? I am thinking to somehow intercept the JSON and write it into my own encrypted file.
Before you jump to conclusions, have you been able to manually modify the cached json at runtime?
If the “cheating” was considered a possible security flaw in the implementation, I would expect any manual modification of that file during runtime to cause a serialization or similar exception to be thrown. The file itself needn’t be encrypted but rather it would suffice to record its timestamp and compare it with the in-memory timestamp.
I’ve ran into this issue myself with a json written by Multiplayer Playmode which I could not even read in and write back unmodified without raising exceptions and that file is developer only and the only reason they might protect it is to reduce support issues. This could indicate Unity has a general purpose system for this attack vector already in place.
Of course to protect against in-memory modifications of a process you’d have to implement far more elaborate (and ultimately futile) measures.
You can not modify it in realtime, sure. But I believe that if you are turning internet off and modifying the file and then reopening internet, the values will change (not tested btw).
Hi @alex11paulescu , @CodeSmile
We appreciate your questions and concerns!
I’ll attempt to respond by providing the explanations (that I am aware of) on why RC chose not to include cache encryption so far:
While encrypting cached data is not too difficult to implement, various concerns have prevented the use of encryption for cached data:
As a result, we recommended that users attempt to avoid storing sensitive or important data in the cache file.
The way the RC works is that upon initializing, cached values are loaded by default, and then only if the RC fetch call is successfull, those values will be overwritten, cache file included.
To your point, that would enable the possibility of changing the cache file on the device while the internet is unavailable, but as soon as the RC fetch call is successful, values will alter as you mentioned.
It’s worth noting that similar cheating could potentially occur even if the cache data were encrypted.
Hackers could intercept and modify the requests between the game client and the Remote Config service, bypassing the cache entirely.
You are bringing a good point, as while encryption can enhance security, a comprehensive approach would be needed to prevent cheating - including encryption, integrity checks (checksum or timestamp as @CodeSmile suggested), and even maybe a server-side validation.
Unfortunately, it might not be evident when a complete solution including encryption for the cache data can be put into place given the priorities and resources that are currently available.
Once again, thank you for your input. We will absolutely take this feature into consideration.
All are valid concerns, yes. Adding encryption would increase the difficulty of RC. But I believe you could give the developer the option to use encryption or not.
I am not saving really sensitive data in the cache, but take this scenario :
I configured an Event in RC. It has start time, end time and paramaters for the reward string (let’s say I am using “coins(100)”).
The user can turn off wifi, go to the cache, change the reward from 100 to 100.000, boot the game, play a level, win the event and get 100.000 coins.
I understand this really is an edge case, but maybe something to keep in mind.
Thanks for the concise answer!
Thanks @alex11paulescu , I agree with you 100%.
It could be really beneficial to give a developer a choice to encrypt the cache file or not, that way they could decide about the corresponding risks.
We will definitely add it to our roadmap!