9

If I understand correctly: NSUserDefaults is an un-secure place to store sensitive data because some settings file can be hacked and the NSUserDefault values can be changed.

What exactly can be hacked and not hacked? Can the Hacker see my app's Swift Code, or do they only see the list of variables and values stored in NSUserDefaults?

Could I create my own "encryption" in my code (where the NSUserDefault values appear like a bunch of meaningless numbers, and the "key" is inside my code with some convoluted mathematical operation to do)? Is this safe?

Note: I don't intend on encrypting anything serious like usernames or passwords, just Highscores and Bool values for whether or not levels/upgrades are unlocked. I don't want to have to learn KeychainsWrappers if my manual solution is safe.

Side-question (though I haven't reached this step yet): How are in-app purchases handled? is there a Bool value that says whether or not an item was paid for, and where is that Bool stored (is it up to you to decide)?

Eric Aya
  • 69,473
  • 35
  • 181
  • 253
mdamkani
  • 305
  • 2
  • 12

2 Answers2

13

What exactly can be hacked and not hacked?

Most everything you can do can be hacked.

Can the Hacker see my app's Swift Code, do they only see the list of variables

A sophisticated hacker can see the executable binary but not the Swift source code.

values stored in NSUserDefaults?

It is trivial to see the contents of NSUserDefaults. See iExplorer and other similar apps.

Could I create my own "encryption" in my code

Sure, but should you?

"Schneier's Law": "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break."

Is this safe?

No it is not safe. If you want use encryption you need a standard encryption algorithm such as AES but it is not that easy to create a secure scheme. You can use a wrapper library such as RNCryptor. But this creates a new problem: where to safely save the encryption key, see next point.

I don't want to have to learn KeychainsWrappers if my manual solution is safe.

Only if you want to securely wan to to save keys and small amounts of data. Security is hard.

You need to evaluate the level of security you need, this included the level of attacker and the value of the data. Attackers run from curious students to nation states. Data values run from Tic-Tac-Toe high scores to nuclear arms details. You need to determine these first.

zaph
  • 111,848
  • 21
  • 189
  • 228
2

NSUserDefaults is just a plist stored in the device filesystem. Its only 'security' is that people have to go into the device filesystem to get to it, which isn't particularly difficult.

According to the apple docs about in app purchases:

After making the product available, your app needs to make a persistent record of the purchase.

source

You can read more in the section about persisting your purchases for more information, but ignore the parts where it says you can use user defaults to do so.

Also I can't ever recommend rolling your own secure storage system if you don't know what you're doing.

The above is assuming you are talking about in app purchases. If you are talking about stuff local to the user, does it really matter if they hack your app? Say you have a system where you have to beat the previous level to unlock the next level. Who really cares if someone edits their defaults to unlock the next level. Its not something they had to pay for so it doesn't affect your revenue stream. In fact, I would argue it's better to allow people who really want to cheat to do so as long as it doesn't affect your revenue or other players.

Will M.
  • 1,864
  • 17
  • 28
  • what about being able to see the code, that's impossible right? Im not looking for a recommendation, I'm asking what the standard hacker is capable of. If they can't see my code, I'm confident i can come up with something annoying and unbreakable enough to prevent high score tampering. – mdamkani Apr 18 '16 at 19:04
  • I thought you were preventing in-app purchase tampering. I dont really see any reason to prevent local high score tampering. – Will M. Apr 18 '16 at 19:18
  • What is a "standard hacker"? You need to evaluate the level of security you need, this included the level of attacker and the value of the data. – zaph Apr 18 '16 at 19:18
  • 2
    If learning Keychain is a hurdle, I assure you that you cannot come up with something unbreakable enough to prevent high score tampering if attackers have any particular motivation to do so. (It is trivial to prevent high score tampering in the general case; just make a game no one cares about.) If you could put it together without a security background, then most popular games would not have fraudulent high scores. Most popular games *do* have fraudulent high scores. That by itself should demonstrate that it is not a simple problem. – Rob Napier Apr 18 '16 at 19:35
  • 2
    (This is not to dissuade you from building a simple obfuscation system like you're describing. I in fact *encourage* you to do so. That is exactly what you should do. It will not be particularly effective, but as long as you keep it simple, it will do your program no harm, and it will be a little effective. Just don't waste huge time and effort trying to make something that really works. It is very seldom worth it, and you will need a very large and ongoing budget to constantly improve it as it is defeated.) – Rob Napier Apr 18 '16 at 19:37
  • Thanks. Regarding in app purchases, I thought maybe it was information that Apple kept track of. Now that I understand it's up to me, it looks like I'll have to implement keychain wrappers eventually. For the less important stuff I'll start with something custom and imperfect. – mdamkani Apr 19 '16 at 04:05