I am storing the key & secret required for API call in iOS keychain using Apple code
My key & secret keeps on changing after every call to API. So once they are changed I save them in Keychain again. So I am accessging the iOS keychain frequently.
My questions are
Is it ok to store key & secret in iOS keychain ?
Does Apple allow this as I am accessing the keychain everytime I need to call API ?
Sure. That's what it's there for.
You access your keychain every time you want to get in your car, right?
Related
I have stored fabric_api key in Info.plist file.But I don't want to include my key and secret in the info.plist file when the the app is live.
what is the best way to keep fabric/crashlytics key secure?
I only know several ways:
Just put it in a constant variable, or if you want under your struct that handles all your keys. That's it.
UserDefaults.
Use libraries to obfuscate somehow your keys, such as https://github.com/orta/cocoapods-keys
Keychain.
The last one is discussed by Apple.
Keeping a private key in a keychain is a great way to secure it. The key data is encrypted on disk and accessible only to your app or the apps you authorize.
https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave
Also some interesting discussions:
In iOS, how can I store a secret "key" that will allow me to communicate with my server?
swift3 - How to protect secret key
I hope this helps.
In my Apple developer account I have created a key for use with APNs across all my apps. On creation it allows me to download it once I have finished. After that the 'download' button is greyed-out and I can't download it again. Presumably this is by design.
Can anyone tell me why it doesn't allow a second download like you can for the certificates/profiles?
You can't re-download the IOS Push Notification Auth key. Only public key is retained by Apple and a private key which you retain and protect.
See documentation section Provider-to-APNs Connection Trust.
Token-based provider connection trust: A provider using the
HTTP/2-based API can use JSON web tokens (JWT) to provide validation
credentials for connection with APNs. In this scheme, you provision a
public key to be retained by Apple, and a private key which you retain
and protect.
You can see warning too when you create an Auth Key.
Download and Back Up After downloading your key, it cannot be
re-downloaded as the server copy is removed. If you are not prepared
to download your key at this time, click Done and download it at a
later time. Be sure to save a backup of your key in a secure place.
I just created new key on developer.apple.com, never download it yet, but I'm still unable to download it (download link is disabled).
Any idea how to get p8 cert from developers.apple.com?
I am 100% new to AWS and to the AWS iOS SDK.
I am using The Standard AWS Code Example. to initialize the Cognito credentials provider. I of course am changing #"COGNITO_IDENTITY_POOL"].
I have noticed that when I do this the first time for a device that NSString *cognitoId = credentialsProvider.identityId; is nil. Is this to be expected? if so at what time is the property available?
Also is my understanding correct that the SDK saves this Cognito ID in the devices key chain? Thus this identity will not change for the device while ever the user backs up his operating system. If for example he wipes his device and freshly installs iOS then a new ID (same app same Congnito pool) will be generated? If however he just deletes my App but later installs it again (no change to iOS), then if I use the same Cognito pool he will be recognized as an existing member with the same ID?
"credentialsProvider.identityId" is null the first time you use the SDK, until it gets refreshed. Once you get an identity from the service, it will get stored in the keychain and the device will always reuse the same one (unless, as you said, the user clears the keychain or wipes the device).
Albert
As Apple docs state, apps can share keychain data if they have the same App ID prefix and they've set the same keychain-access-groups in Entitlements.
However, I've been able to access shared keychain data from the app that has a different App ID prefix as long as I provide the proper keychain-access-groups as a hard-coded string. Like ABCDEFGHIJ.my.keychain.group.
It seems that keeping the keychain-access-groups value secret is the only thing that prevents someone from accessing the keychain data. Obviously, since it's just a plist value, this is not safe at all.
Is there any way to ensure that an app that is not included in my Apple Developer Program will not be able to access shared keychain, even if it knows my keychain-access-groups value?
Does anyone have any tips migrating from the old iOS FB SDK (the one hosted on their GitHub account) to their .framework (package-based installer) one? I'm having issues getting the existing auth token and expiration date objects to validate against the new FBSession object.
Here's the situation:
In the old SDK/technique, the Facebook iOS SDK required you to save things like the auth. token and expiration date manually through your own storage mechanisms. In the new framework based SDK they now handle this for you, but in order to migrate users (i.e. not have them re-login) I need to provide this information to the new SDK.
It winds up being that Facebook is storing the K-Vs in NSUserDefaults and they even tell you the root key name as well as all the keys for the nested K-Vs of the dictionary they use to store this information.
Their token class FBSessionTokenCachingStrategy even has a class method to verify if an NSDictionary validates to a proper dictionary that establishes a usable Facebook session
+ (BOOL)isValidTokenInformation:(NSDictionary*)tokenInformation;
So I've taken my preexisting auth. token and expiration, put them in a new dictionary, stored it in the proper key'ed location and synchronized NSUserDefaults.
So far so good right? Well once I initialize a FBSession object via
- (id)initWithAppID:(NSString*)appID
permissions:(NSArray*)permissions
urlSchemeSuffix:(NSString*)urlSchemeSuffix
tokenCacheStrategy:(FBSessionTokenCachingStrategy*)tokenCachingStrategy;
The whole key is removed from NSUserDefaults and the session object's state property is in the state of FBSessionStateCreated (i.e. no preexisting state) vs what it should be FBSessionStateCreatedTokenLoaded (i.e. it knows it has the locally saved properties and is ready to be checked online).
Why is it being removed? It validated against the class method.
Thanks
It turns out that the local storage object for newer Facebook SDK also preserves the permissions list related to the token. This wasn't required before so while I didn't have it saved locally, my permissions list did not change. So what I did was also save the permissions list into the new storage object (totaling 3 keys: auth. token, expiration date, and the permissions list).
Once I had done this, creating/initializing the FBSession object did not remove my locally stored object and upon invoking openWithCompletionHandler: it established the expected session state to FBSessionStateOpen.