Where to store sensitive data based on the app's environment?

I want to store my client id and client secrets to use in an API? These values changes based on the environment (development and production), so I was thinking about storing it in a .plist file, but I don't know how secure it is, or if it's a good practice.

Good call—don't ever put those in a plist file. They're unencrypted and ridiculously easy to read with other software. Now, if you were going to put that plist inside your asset catalog (instead of just in the Resources directory), that could work. At compile time, the asset catalog gets rolled up into an Apple-proprietary format that cannot be easily read. At runtime, you'd just use the NSDataAsset class to retrieve the plist, which you could easily parse and then use. Of course, this isn't exactly going to offer bulletproof security, but if a would-be attacker doesn't know where to look, the change of being compromised is much, much lower.

Hi bob! Thanks for the answer. I've seen that Keychain is a good choice to store sensitive data. Can I put these data in there? I just can't find a solid way to store this kind of data 😟

Unfortunately, the keychain isn't designed for stuff like this. It's intended for the end-user's secrets, not yours. If you put your secret keys in the keychain, sure, they'd be encrypted, but the user would be able to get them out very easily with just his password. That's not what you want. 😮

It isn't really. Maybe a better approach is to generate a certificate or key pairs to avois storing these informations. What would you do in this scenario?

That wouldn't work either because you'd still need some kind of persistent credential to be shipped with the app. For example, in order to create or modify API keys for my MailChimp account, I have to log in with my username and password.


Perhaps you should look into whether or not it's safe to just hard-code that key using, say, a string literal. (Back on that "if they don't know where to look, they won't find it.")

> At runtime, you'd just use the NSDataAsset class to retrieve the plist, which you could easily parse and then use.


Is it really that difficult to reverse engineer the compiled asset catalog? Pretty sure there are tools around that can grab all the images out of an Assets.car file. I haven't used Asset catalogs to store other kinds of resources but I would guess that extracting other resources out besides images wouldn't be that difficult?


I'm not really sure how other resources in a Asset Catalog get compiled. I know "Generic OS X" icons just spits out a .icns file in the resources folder.


They could just dump out all the strings if you used a string literal. Maybe something like this would be "good enough"? h t t p s://github.com/pjebs/Obfuscator-iOS/tree/master/Obfuscator

Let me be a thread necromancer here. Turns out that the better way (if we can say that) to do so is implement somethind like OAuth2, which will open a SFSafariViewController and let a web page take care of the keys. That works well.

I noticed that Dropbox seems to use a native screen to log in. No webview, no SFSarariViewController, which is strange. And also, how could I use an API key with an App that does not need login? Store an API key also does not seem to be a great solution for obvious reasons.


That's really confusing.

Where to store sensitive data based on the app's environment?
 
 
Q