I am using keychain in my macOS app to store jwt tokens (access and refresh)(kSecClassGenericPassword) and I have figure out that I can't manage existed data via the same app with another name.
I have build two equal application with different app names:
for example: App1.app and App2.app
Note: it's the same build, but with only different - app file name.
And if I created the keychain item using the first app (App1.app) I can't remove it from the second one.
If I double click on keychain item in Keychain Access default App I can see that there is only one app in Access Control tab (with the name App1.app).
Is there a way to give the access to keychain ignoring app names. Because user can change the name, or make a duplicate of the app.
Is there a solution of this behaviour?
Thank you!
So to solve it I set Keychain Sharing Capability and set (for macOS It's very necessary!) kSecAttrSynchronizable or/and kSecUseDataProtectionKeychain
More info here: https://medium.com/#bhojwaniravi/making-mac-oskeychain-behave-as-ios-keychain-60eedb37c173
Related
I store the token received from an API sign in process in the user's keychain. Then for all further requests to the API I get the token from the keychain to send to the API. This happens with each request made to the API. As I have understood the keychain is the right place to store sensitive information, so I'm not storing the token in the user defaults.
On iOS everything works as expected, but on macOS, there's an alert appearing that the App wants access to the keychain. The user can then select to allow it once or to allow it always. This has two major issues:
if the user chooses "once" the dialog will appear over and over again with each request the App does.
if the user chooses "always" the dialog will not appear for some time, but after a while it will reappear nevertheless.
Why is this behavior totally different between iOS and macOS? Or did I forgot to configure something?
From a security point of view, would it be okay to read the token once at the start of the app and store it in a property?
Although the Keychain on iOS and macOS share lots of similarities, there is one big difference between the two. iOS only has a single Keychain, whereas macOS can create any amount of Keychains. You can find more info on that here.
This means that we will have to tell the macOS Keychain to behave like the iOS Keychain, which we can via the kSecUseDataProtectionKeychain key, documented here. Setting this flag to true should solve your issue.
I have an application already in the store that use Keychain to store passwords.
I want to publish an update of the application, the problem is that I don't have the original certificate anymore (it was expired and I created another).
Reading Apple's documentation it says:
Note: On iPhone, Keychain rights depend on the provisioning profile
used to sign your application. Be sure to consistently use the same
provisioning profile across different versions of your application.
If I edit my provisioning profile with a different certificate, will my users lose their passwords when I will upgrade the application?
Thanks
if you can upload the app into the store (so update the old one), the users will not recognize anything of this ;)
What's saved in their keychain will be bound to the Bundle an stays at least until the application is deleted.
You can revoke and re-create your cert, and assign it to your provisioning profile without any further consequences.
In the Keychain Services Programming Guide it states the following:
"On iPhone, Keychain rights depend on the provisioning profile used to sign your application. Be sure to consistently use the same provisioning profile across different versions of your application."
Which I have no problem with but I would like to test that if I provide an update to my app in the AppStore that it will still be able to access the old values stored in the keychain. I have tried to test by updating the app with a version signed with an ad-hoc distribution profile that contained the same bundle id and product name as the original but it could not access the old value in the keychain.
Is the only option to submit the update to the AppStore and hope that it will work?
This is a good question.
One of the main reason why you might want to store some data in the keychain is to prevent malicious users from accessing it. This is quite a dry sentence on its own so I recommend reading about how someone might access that data.
Another way to access keychain data would be to create a malicious app with the same app ID as the target app. Apple have secured this route by requiring the provisioning profile to be the same.
So, to answer your question, you can only test the keychain data in update from the same provisioning profile, i.e.
Ad hoc to Ad hoc
App store to app store.
App store to app store is not really an option since it will be too late by then (your update will be on the market). So instead you need to delete your app store app and install an ad hoc version. Then recreate your data on the keychain, then update to the latest ad hoc version and test that it worked.
Of course this requires you to have an archived ad hoc version of the app thats currently on the app store. If you don't have this, then its not possible to test an update.
Unless I am mistaken, to update an app in the app store you need to use the same provisioning profile. Therefore, since you will be using the same profile, you should have access to the same keychain items.
It's actually not the provisioning file that matters, but the app ID. Specifically the Bundle Seed ID that you set when creating an App ID. Keychain access is governed by it. So as long as your profile uses an app ID with the same Bundle Seed ID you can continue to access the info in the keychain. I have a few apps that do this.
This allows you to to create a suite of apps that can all access the same keychain items as long as you set them to use the same Bundle Seed ID. So if you do a light and a pro version, they can both access the same keychain info while maintaining separate bundle identifies for things like user defaults.
SFHFKeychainUtils may be your good choice.
It's a wrapper to access keychain.
More about: SFHFKeychainUtils :http://www.ioslib.com/archives/sfhfkeychainutils/
Here is my situation...
I want my password to be encrypted and at the same time I want it to be in iPhone settings (by adding resource and accessing it through NSUserDefaults), but i think NSUserDefaults saves the password or information in plane text and iPhone takes care of everything in its Settings app if there is any change or whatever.
How could I make sure that information that I see in the Settings is coming from and going back to Keychain but before that, Is it possible? If not any other way? May be writing encrypted file?
I DO NOT want settings to be in my app.
thank you
us
The Keychain service cannot be invoked from within Settings, you need to do this within your app. It is good practice to ask users for their password within your app in a login page or UIAlertView at least (like the App Store does).
From the user's point of view, they don't want to have to launch Settings, enter their password, and then launch your app to log in, they want to do it all in one place.
How do I remove an App ID from the developer program portal area? I mistakenly added a couple of app id's under the wrong login and would like to remove them, but I am not seeing a way to do so.
Update: You can now remove an App ID (as noted by #Guru in the comments).
In the past, this was not possible: I had the same problem, and the folks at Apple replied that they will leave all of the App ID you create associated to your login, to keep track of a sort of history related to your login.
It seems that they finally changed idea about.
App IDs cannot be removed because once allocated they need to stay alive so that another App ID doesn't accidentally collide with a previously existing App ID.
Apple should however support hiding unwanted App IDs (instead of completely deleting them) to reduce clutter.
In the iOS Dev Center developer navigate to "Certificates, Identifiers & Profiles > iOS Apps > Identifiers > App IDs"
Find the app id you wish to delete, highlight it and select "Settings". At the bottom of the resulting screen there is a "Delete" button.
Previously the only way to do this was to use a Safari & Chrome extension written by Simon Whitaker
app-id-sanity downloads
It gives you an "Active" checkbox next to all your App IDs and allows you to relabel them to alter how they appear in the App ID drop-down when creating new provisioning profiles.
As of Apr 2013, it is possible to delete App IDs.
As of Sep 2013, it is impossible to delete App IDs again after the big outage.
I hope Apple will put it back.
As of mid 2014, it is possible to delete App IDs again. However, you can't delete id of apps existing in the App Store.
Delete application IDs is allowed. Make sure you deleted all certificates, APNS certs and provisioning profiles associated with your application. Then go to Identitifies --> App IDs, select the application ID, Edit and Delete button should be enabled.
As #AlexanderN pointed out, you can now delete App IDs.
In your Member Center go to the Certificates, Identifiers & Profiles section.
Go to Identifiers folder.
Select the App ID you want to delete and click Settings
Scroll down and click Delete.
When I do what explains some answers:
The result is:
So, anybody can explain really really how to delete an old App ID?
My opinion is: Apple does not let you remove them. I suppose it is a way to maintain the traceability or the historical of the published.
And of course: application is no longer available in the App Store. It was available (in the past), yes.