Error -34018 (errSecDefault)

[tonyxiao]

Sometimes I'd see the following error

(lldb) po error
Error Domain=com.samsoffes.sskeychain Code=-34018 "errSecDefault" UserInfo=0x17d3f070 {NSLocalizedDescription=errSecDefault}

But I have no idea what errSecDefault (code -34018) means nor how to resolve it. Any ideas?

[aspyct]

As an additional information, we have the same problem in our project, which doesn't use SSKeychain. We started experiencing the problem with iOS7 only with the test runs. Right now, about a month later, we discovered that we have the same problem with an iPad mini 1 running iOS 6.1. But it works with an iPhone 4S running the same OS version.

If you have any ideas, I'd be interested. I'm also open to contributing to this issue, as we're experiencing the same problem, but this will be planning-constrained.

iPhone 5S, iOS7: fail iPhone 5C, iOS7: fail iPhone 4S, iOS7: fail iPad mini 1, iOS6: fail iPhone 4S, iOS6: success

[calebd]

Are you guys using access groups or iCloud syncing? Error -34108 is defined in SecBasePriv.h as "missing entitlement".

[aspyct]

Nope, none of the two.

[iwasrobbed]

:+1: Just started seeing the same issue consistently after upgrading to iOS 7.1 SDK. By the way, this only happens in a testing environment running the app through KIF on a device. If I run normally, it works just fine and it also works fine on the simulator during test.

This seemed to fix it for me during test: http://stackoverflow.com/a/22305193/308315

[soffes]

PRs welcome :)

[TedAvery]

:+1: Happening to me as well on iOS 7.1.1, but very sporadically, can't find a way to recreate it myself.

[rsanchezsaez]

I'm experiencing this as well when trying to get previously stored items. They weird thing is that it seems to be happening semi-randomly.

In our case it seems related to trying to access the keychain in code inside a dispatch_once(&token, block).

[soffes]

@rsanchezsaez hah! That'll do it :)

[rsanchezsaez]

@soffes: How do you mean? That accessing the keychain inside a dispatch_once(&token, block) block produces this error? They weird thing is that we sometimes get it and sometimes don't (with the code being at the same exact place).

[soffes]

Oh, I thought you meant it was only happening sometimes because you were only executing the code once

[rsanchezsaez]

No, the code is ran once per application lifetime, but sometimes we get the bug and sometimes we don't (we have experienced the bug on several application runs, both in Debug and Release mode). :-)

[ccwasden]

I am seeing -34018 "errSecDefault" on occasion, has anyone figured out what is going on or how to avoid it?

[marknorgren]

I am also seeing the -34018 intermittently.

Error Domain=com.samsoffes.sskeychain Code=-34018 "errSecDefault" UserInfo=0x19fe8c10 {NSLocalizedDescription=errSecDefault}

[rvi]

Same here, on iOS 8.1 on iPhone 6. :/

[ccwasden]

So, I was getting this error after accessing the Keychain around 100 times or so. Initially the keychain worked fine but then at some point it would just stop working and I couldn't access using sskeychain. Any chance it is connected to too many queries on the keychain in a short period of time?

[abc2mit]

I'm also getting this issue intermittently now on iPhone 5s, iOS 7.1.1.

It's weird.. I'm getting the error both on retrieve and save. It seems to be occurring on launch or re-launch of the app. I wonder if it's hitting the keychain too often?

[abc2mit]

Does anyone know if the iOS Keychain is thread-safe? I'm actually hitting the iOS Keychain from multiple threads, usually in parallel, so I'm not sure if this is what is causing the -34018. I've also tried switching from kSecClassGenericPassword to kSecClassInternetPassword, but there doesn't seem to be an effect.

[abc2mit]

@ccwasden That's an interesting thought. That might be true. Or a frequency issue, like 100 requests/hour. I still run into this once in a while, but I now built a cache around it. That's the only thing I can think of, since no one else seems to have any resolution.

[chrisballinger]

We are seeing this randomly as well, haven't been able to figure it out yet. The most frustrating part is that sometimes quitting the app and running it again solves the problem. I've also only seen it when debugging and never in "release" builds so far.

[maqoo]

Hi - we use SSKeychain in our project right now and get this error a lot - debug only though.

Ussually it happens when updating code from git repo at first launch of debug version of the app (this one is actually fixable with the code signing script from http://stackoverflow.com/questions/20344255/secitemadd-and-secitemcopymatching-returns-error-code-34018-errsecmissingentit/22305193#22305193 )

Second thing is that when we use UIImagePicker to capture some photos. We try to access the keychain when UIImagePicker is visible and we can do it with no problem. But right after the image picker control is dismissed, this error starts to occur.

[abc2mit]

@chrisballinger @maqoo Thanks for the updates! I haven't yet incorporated downloading remote logs from my app yet, so I haven't see if there are any issues from release versions.

[skingtree]

I also have this problem. Some critical data not saved in keychain and retrieve nil when the app relaunch. Just like something we trust not work in 100%.

[soffes]

This is not an issue with SSKeychain. It is an issue with Keychain. Like the readme says:

Working with the keychain is pretty sucky. You should really check for errors and failures. This library doesn't make it any more stable, it just wraps up all of the annoying C APIs.

Good luck everyone.

[paulbruneau]

I'm glad to see I'm not the only one. When my app gets this, it basically "logs out" the user. I am going to have to re-think what I do when I see this.

[diegopizzocaro]

Experiencing exactly the same and only in debug. We debugged it a lot and it seems an issue accessing the keychain when the app is launched from the background. This is only happening with the debugger (i.e. when launched from Xcode). We think the issue might be related in our case to the debugger keeping alive the app even if it should be killed by the OS. We tried in fact to run the app and then put it in background and launch many other app to occupy RAM. With the debugger the bug came up when resuming the app from the background, while without the debugger it didn't (we did run at least 10 tests each).

Note that if you're accessing the keychain in the background you should have something like this in your didFinishLaunchingWithOption

[SSKeychain setAccessibilityType:kSecAttrAccessibleAfterFirstUnlock];

[tspecht]

Has anyone ever figured this one out?

[paulbruneau]

I figured out don't use keychain except as a backup for if they uninstall your app.

[cipherCOM]

After seeing https://github.com/soffes/sskeychain/issues/52#issuecomment-70866718 from diegopizzocaro we could solve this.

We used the keychain to store Facebook tokens in a special way (so the main and WatchKit app could access it / enabled keychain access groups). Most of the time the error arose after allowing the application from within Safari which causes a application change to finish the login flow. Coming from the background we had to store token but the [[UIApplication sharedApplication] applicationState] was still UIApplicationStateInactive. This caused the famous -34018 error for us.

After placing the mentioned kSecAttrAccessibleAfterFirstUnlock setting the error was gone.

[elviin]

@cipherCOM FXKeyChain uses kSecAttrAccessibleAfterFirstUnlock and still has the same issue.

[benguild]

I'm using "kSecAttrAccessibleAfterFirstUnlock" and noticed that if I have the Control Center screen slid-up over the app (UIApplicationStateInactive?) I sometimes start getting "Keychain error: errSecDefault" and it breaks the app until it's restarted.

Moving to a strategy of storing the keys in memory locally instead of just fetching them from the Keychain every time, but man... this is kind of annoying. Is there any real workaround? This is on iOS 8.3 release.

[elviin]

I have received an email from the Apple support stating that: "Our engineers have reviewed your request and have determined that you are experiencing an issue for which there is no known workaround at this time."

[benguild]

That sucks. I think I can maybe shift this app over to NSURLCredential instead, so I'm going to try that. Has anyone run into this issue with that class?

[paulbruneau]

Great discovery about the control center. I switched to using NSUserDefaults as my primary storage (my data is not very sensitive).

[benguild]

Anybody testing in iOS 9 yet? Wondering if it's OK to reverse to keychain use in iOS 9+.

[serieuxchat]

Have the same problem on iOS 9 (beta 2) :-(

[benguild]

:(

[danielgalasko]

This is a bug with the Security framework. Apple engineers are actually still trying to fix it https://forums.developer.apple.com/thread/4743 Strangely for me, deleting and reinstalling fixed issue

[elviin]

I have decreased the number of reads from the keychain (reading just at the application start and then only if necessary) and I can not reproduce the issue anymore (iOS7.x, iOS8.x).

[benguild]

So you're just keeping the info in memory the whole time?

[danielgalasko]

@elviin In my particular instance this happened sporadically (meaning limiting the number of reads had no effect) and when it did occur the Keychain was unusable. The solution (sadly) pointed out in the Apple Developer Forums was to simply raise an NSException and crash the App. Relaunching the App would then reopen the Keychain.

[benguild]

That's super annoying!

[elviin]

@benguild Yes, that is not as secure as if the info was read each time, but it was only way I could avoid the error. I use a dictionary to avoid the read.

[elviin]

@danielgalasko My apps do not allow this kind of handling. I read the secret at the app start, delete the secret from the memory if it is no more needed by the user. I also tried to implement an exclusive access to the keychain. It did not help.

[elviin]

@benguild How about the NSURLCredential? Did you try to use it?

[benguild]

NSURLCredential has the same problem. I tried that. It still uses the Keychain and suffers from the same dropout.

[elviin]

@benguild :/ Thanks.

[jonypz]

Same problem here on iOS 9. Whats the best work around?

[benguild]

It seems like throwing an exception in the rare instance that this occurs is the best solution.

[mAu888]

For me this was not happening rarely. More like in 1‰ of cases, which for a bigger user base is quite a lot. My not that nice workaround is to store the secret on app start as a property in my keychain wrapper and fall back to that if reading fails. Fixes the issue but of course I'd Love to get rid of that workaround.

[elviin]

I do the same and it has eliminated the issue.