koobas.hobune.stream
Too subjective and argumentative
Secure PlayerPrefs using hash signature
I am trying to create a relatively secure way to store some values in a way that the user will not be able to easily modify manually. The target platform is iOS and possibly Android.
My current plan is this:
Save the value using PlayerPrefs.
Save an MD5 hash of the value + secret string + unique device id.
Now, as far as I understand, the value can only be modified by my scripts, unless someone knows the secret string, and even so, it will only help for manipulating that specific device.
Does anyone see any major problems with this approach? Keep in mind, my main use case is to store some values that define what in app purchases were purchased.
Just to be clear, I am not interested in "you can do this instead" answers, but rather to understand what can be the flaws of the above approach.
For context, I would say that I have tested (and decided against) these:
Encrypted custom XML
SecurePlayerPrefs / EncryptedPlayerPrefs assets (available on the asset store and somewhere in the forums respectively)
Any solution that involves a server
Also, assume I have read most, if not all of the Unity Answers and Forums pages that I could find on the subject.
Thanks in advance.
What's the reason you don't want to use Secured PlayerPrefs? It's great.
https://www.assetstore.unity3d.com/#/content/4962
http://forum.unity3d.com/threads/157606-Secured-PlayerPrefs-Release
"Just to be clear, I am not interested in "you can do this ins$$anonymous$$d" answers" Right. Just to be clear, I'm just interested in why you don't like Secured PlayerPrefs.
"to understand what can be the flaws of the above approach "
well the unique device id is instantly knowable by anyone , so it's almost not worth putting it in as a salt
"$$anonymous$$eep in $$anonymous$$d, my main use case is to store some values that define what in app purchases were purchased"
Alright, I'll keep that in $$anonymous$$d :) is this iOS in app purchase? In that case you have your own stateful server anyway to check that receipts are used uniquely, so just use that?
(if you don't check receipts on the app store you will be instantly, widely "hacked")
Als note that you're including all of the relevant .net library anyway to do a hash, so would it actually be simply easier / more $$anonymous$$ISS for you to just encrypt the string?
$$anonymous$$y concern with the approach is that the secret string will be stored in the application and so can be reversed engineered out of the application. Your approach may be okay to stop casual piracy, but is not sufficient to prevent piracy. Never trust anything on the client.
Well, not many things can actually prevent piracy, and that is not my intention to try here. All I want to do, is to make it less obvious for the average person who browses their iPhone folders to just change a .plist value in order to get that IAP. I am hoping that my approach would force them to either buy, or to go get that pirated version that someone else made, if it is available.
@Fattie - It's not that I don't like these external solutions - I just don't need them. They seem to provide more or less what I do here, so I am rolling my own solution with more control and less external dependencies. A matter of preference.
As for doing a two way encryption ins$$anonymous$$d of one way signature, it will suffer from the exact same issues as a one way signature so it is immaterial I think.
If by "the casual hacker" you mean someone who goes looking for a text file, reads it, mods it and off they go then any kind of $$anonymous$$D5 hash is overkill. Just XOR all of the characters with something and be done with it. Anyone who wants to hack your game and knows what they're doing will get through it by looking for things which could be your secret string in the decompiled code, which will only be at all difficult if you've obfuscated the code you ship - even they I bet there's a 100 programs that search IL assemblies looking for $$anonymous$$D5 hash algorithm/access to standard ones.
