This question already has answers here:
Secure keys in iOS App scenario, is it safe?
(3 answers)
Closed 3 years ago.
I am working on a simple iOS app in Swift that uses an API that I pay for. I do not have a ton of resources and have yet to find a simple/up to date solution to this issue. I want to protect my API key and not put the key directly in my code where I make requests (I have heard this is best practice).
What would be the simplest way to protect my API key from someone taking apart my code and using it.
I've heard something about using Keychain but I'm unsure if this is the best route.
class APIService {
static let shared = APIService()
private let token = "(my token goes here)"
//...various API request functions
}
There is no easy way, nor is there a way to completely protect them from attackers. You can always do some simple key obfuscation or store them in a server but if a hacker can reverse-engineer your code they can likely reverse-engineer your obfuscation.
It'd be good to develop safety measures to take if someone does get your keys (database backups, etc.. ).
This link helped me when I was originally looking into this topic for one of my apps.
NSUserDefaults:
NSUserDefaults is simple and effective for saving small datas like NSNumbers or NSStrings, or even saving remember me option for saving ur state of UserName. NSUserDefaults is no way stored securely as it's easily gets Hacked.
KeyChain:
Best place to save tokens, api keys. Find the below apple documentation which describes more,
**“An encrypted container that securely stores small chunks of data on behalf of apps and secure services.” "Simply a database stored in the file system.”**
KeyChain Documentation
And here is the example of Swift Version with simple way to store and retrieve data using KeyChain
https://stackoverflow.com/a/37539998/1244403
Related
I just wanted to do a quick sanity check with StackOverflow to confirm my suspicion. I'm creating an app and was tempted to use FMDB in Swift to store some data.I am treating this data as public in the sense that I assume it can be tampered with (and thus untrusted). This is because, after all, unlike a web app, this app runs on a user's device and thus they can access the .sql file and alter the database.
If I wanted to store information like if a user purchased something, unlocked certain weapons, or other data that I do not want to be altered in any way, I should not use a local database on the user's device.
Would you say this is correct and safe to proceed under this assumption? If I was looking to use the database to persist something important that took place, what would be a good approach? encryption with the key in the app, or maybe a hash or something?
If you want to secure your database, FMDB includes hooks for SQLCipher, which you have to obtain separately. See the various FMDB Encryption Methods that you can use once you have SQLCipher included in your project.
I am building an iOS app for someone. The app will be used to take mock exams on for a professional license. The question data is stored in Core Data but the question and answers strings need to be encrypted as the client spent a lot of time writing them and doesn't want someone else stealing his work to use in a competing product.
So what I want to do is set the attributes in core data to transformable, use a custom NSValueTransformer to transform the strings to NSData and while they are being transformed use RNEncrypt to encrypt and decrypt.
So far so good.
Here is my predicament: I need to use a key to encrypt and decrypt the data but how do I get/create it?
My options:
hardcode it == bad!
generate key and store in keychain == not the right type of security. i.e.. does not protect against owner of the device.
generate key from user password == no other reason for the user to have to login.
the app connects to a server and gets a key with some authentication stuff(I don't know what is involved exactly) == I don't want to rely on a network connection for the app to work.
obfuscation, I feel like if I create a string from bits of other strings and method sigs and then hash it then that will be enough == It probably won't be.
My questions then are these:
- Obfuscation, can it be enough, has anyone else had success with it?
- From my research I've learnt that a hacker with an ipa can see all the hardcoded strings, class names and method sigs but they can't see the code inside the methods (is that correct?), so how could someone read the key if it was built up/generated inside a method?
- As the title, Can I use Obfuscation?
- Are there any options I have missed?
For the record, if I have to then I'll make people register and login.
You cannot store data locally securely. As soon as you are able to decrypt it an attacker can as well. That goes for EVERY encryption technique. No matter what you try.
You have to store the data or a different decryption key for each data point on a server and retrieve it one by one every time. You additionally have to make sure that the user does not just send 100s of requests and retrieves all data by hand.
Note that storing just one key on a server will result in the exact same thing as writing it hardcoded in the app. And not limiting the requests will just cause the attacker to need a little more time than just looking at an already decrypted local db.
Of course you can obfuscate it to make it seem like it has some good encryption behind it - but if someone WANTS to get the data, he will be able to.
Regarding the code in an ipa: you will not be able to see the original code but you will be able to see some code that produces the same output as the original code. As long as the device can produce the valid key, an attacker can as well.
I do not know if there is a huge community out there that is looking through random apps to steal some of its internal questions / answers / data, I doubt it.
You just have to make the product sooooo good that no competing product with the same data has any chance against it. The data itself can always be "stolen".
I am storing secure data in the keychain that should be maintained only within my app. During app running this data is retrieved to some variable. It seems like it is possible to crack my app in order to read that value or even dump the whole keychain, but my question is it possible to the "hacker" modify that data i.e. modify at runtime area of RAM that holds this variable and make my app to update keychain with new value? And I also have setter method for that property, which saves it to keychain, is it possible to investigate the address of that function and force call my method with custom value?
I already looked here and here for best practices, read answer at Quora, that and that articles, looked for ios-keychain-analyzer project at GitHub but there is no mention about changing data, only about reading
I'm learning to build iOS swift apps, and I'd appreciate guidance on what storage options to use for different parts of my app. Perhaps examples of how other professional apps architect their storage would be helpful too.
To be specific, I see my options as
an independent MySQL DB
amazon s3
core data
nsuserdefaults
keychain
The app allows users to see/stream/download/upload videos and photos to their account/app as well as do all the normal voting, customizing user preferences, etc. This is an arbitrary app example though. A social media app storage would also be a good case study for me.
Given the variety of functionality to implement, I'm curious as to the best practices for storage architecture in maintaining sessions, persistence, and security.
Right now all I've implemented is having the user create an account and login by doing http requests to the MySQL DB. And i upload and download media from my s3. Each time user data is pulled anew from the DB.
Should i cache/archive stuff into coredata to make it faster for the user?
If a user wants the app to "remember me", where is that data stored?
Instead of straight http calls for logging in, should i do something with keychain? (keychains are the only thing i haven't implemented yet in that list. The rest I've messed with independently)
I've also heard nsuserdefaults is only to be used for user preferences.
Thanks for all advise.
Yes You should use core data for better performance.
Core Data would be a much better tool for the job:
->No mismatch between cache index file and actual data stored;
->Trivial querying;
->Nice and easy object oriented code.
NSUserDefaults
If you want to add Remember me option you have to use NSUserDefaults. It will store in plist file. For more information you should go through this.
KeyChain
Sensitive data like passwords and keys should be stored in the Keychain. Apple's Keychain Services Programming Guide states that a "keychain is an encrypted container that holds passwords for multiple applications and secure services. Keychains are secure storage containers, which means that when the keychain is locked, no one can access its protected contents". Moreover, in iOS, each application only has access to its own keychain items.
You interact with the Keychain by passing in a dictionary of key-value pairs that you want to find or create. Each key represents a search option or an attribute of the item in the keychain.
I use my app to download file then I save into IsolatedStorage.
Can someone hack and get my files or folders from my app?
I do not know how IsolatedStorage protects its data? Do we have another ways to protect data in IsolatedStorage?
Yes your data is vulnerable.
If this data contains user details, like emails, passwords or even personal information then this should be made secure.
If you are storing information about a user's favourite colour or favourite car then this CAN be deemed as "not sensitive" and you will then have to decide whether you want to protect this.
Always assume that people can get at your data. It's just a matter of time before they can access it (just look at how people have jailbroken the iPhone and a vast array of other smart phones for that matter).
Remember Security is not obtained through Obscurity
The following link has good answers in relation to Isolated Storage on Windows...
https://security.stackexchange.com/questions/5660/how-secure-is-isolated-storage-on-windows
From within a managed application it's not going to be possible to access the Isolated Storage of another application. However from native code that's another matter, and WP8 has support for native code...
http://msdn.microsoft.com/en-us/library/windows/apps/jj681687(v=vs.105).aspx
Plus The following article asserts that there's only a registry in the way of a hacker who wants to get unmanaged code on to WP 7.1...
http://www.wpcentral.com/let-hacking-begin-how-windows-phone-7-can-run-native-unmanaged-code
So on WP7 it's pretty clear your app shouldn't store any sensitive data in isolated storage on WP and on WP8 it's even clearer. If you can avoid putting sensitive data in isolated storage do so, otherwise you'll need to encrypt the data, and then of course you need to consider the security of the encryption and the keys used to decrypt and encrypt the data. The following looks like a good guide on how to do that best...
http://msdn.microsoft.com/en-us/library/windows/apps/hh487164(v=vs.105).aspx
At the end of the day security is nothing more than a series of hurdles for a hacker, ultimately they'll probably get access to the data if they're really determined and have the skills and resources available to do so.