Skip to content

Loading…

Error -34018 (errSecDefault) #52

Closed
tonyxiao opened this Issue · 81 comments
@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
Collaborator

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
Owner

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
Owner

@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
Owner

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?

@mrkd

I am also seeing the -34018 intermittently.

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

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
Owner

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.

@soffes soffes closed this
@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.

@nicklockwood nicklockwood referenced this issue in nicklockwood/FXKeychain
Open

Error with iOS8 & XCode 6 #18

@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];

@zinthemoney zinthemoney referenced this issue in venmo/VENTouchLock
Closed

Random False Positive #34

@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 #52 (comment) 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
@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.

@laurentmorvillier

I just want to point out what happened with me.
I could reproduce 100% after using the UIImagePickerController and AVCaptureDevice. Don't know which of the two of those would cause the bug, but it looks similar to what @maqoo reported.

@danielgalasko

@laurentmorvillier could you elaborate further please. You mean accessing credentials after showing Picker of Capture Device reveals this issue? This definitely needs to be reported to Apple then.

Unfortunately I'm not showing any of those components and this event manifests sporadically

@laurentmorvillier

Yes, I have a process that uses the two components as a sequence. After that, accessing the credentials gives the errSecDefault error.

@RebornSoul

have the same issue

@juliantejera

Same issue here on iOS 9

@BrightsCode

Same issue here on iOS 9 too.

@StevePetersenSIkka

same issue on ios 9

@drewmclean

Same on iOS 9

@BrightsCode

I used UICKeyChainStore to replace sskeychain for now.

@paulbruneau

If it uses the keychain you will likely have the same problem. It's a keychain issue, not an SSKeychain one. See Sam's note above from months ago

@podywu

Same on iOS 9

@abc2mit

We all know this is an issue with the Apple Keychain and not SSKeychain. But this seems to be the main thread where everyone is reporting this issue.

I switched to NSURLCredential to try to mitigate this issue, but I end up with basically the same problem (in fact, NSURLCredential seems to throw even more issues when debugging).

This problem seems to be only an issue when in debug mode. On the Apple developer forum, I found a suggestion to install the app manually, launching it manually, then attach the process (https://forums.developer.apple.com/thread/4743). I haven't been able to test this yet, but as soon as I do, I'll report back. In the meantime, let us all know if this is a temporary way of solving the problem when running a developer build and debugging locally.

  1. Build and install to the device manually. You can do this by dragging the app from the build folder to the Installed Apps list in the devices window on Xcode. (Credit to http://stackoverflow.com/questions/3176666/build-and-install-without-run-in-xcode.) The default build folder should be located at:
    • (Xcode)~/Library/Developer/Xcode/DerivedData/[app name-hash]/Build/Products/Debug-iphoneos. If you can't find it, you can go to Preferences -> Locations -> Derived Data to check. There's a link there you can click to open the folder in Finder.
    • (AppCode) ~/Library/Caches/AppCode33/DerivedData/[app name-hash]/Build/Products/Debug-phoneos . You can also do Run -> Show Build Folder in Finder
  2. You can then attach the debugger to the process. This is not yet available in AppCode, but you can do this in Xcode by going to Debug -> Attach to Process. Your app should be at the top of the list. (Credit to http://stackoverflow.com/questions/9721830/attach-debugger-to-ios-app-after-launch)
@paulbruneau

It definitely happens in production code

@elviin

It happens also in the release configuration. @Abc2mit Apple has confirmed on my request there is no workaround yet. Since I needed to store just password and login name I switched to the Keychain Item Wrapper from Apple. It seems in my case the issue is much less frequent.

@danielgalasko

@elviin thats very interesting. Could you elaborate as to what is different with Apples code? My understanding is that this is all inside the keychain itself and not a side effect of the usage of the Keychain. could you post a link to Apple's code?

@elviin

@danielgalasko I use the kSecValueData key for returning/storing password and kSecAttrAccount for returning/storing login name. And it did not fail to store/load until this time. The answer to your question I do not know yet because I did not investigate on the issue in detail.

#import "KeychainItemWrapper.h" // https://cocoapods.org/pods/KeychainItemWrapper

@property (nonatomic, strong) KeychainItemWrapper keychain;
....
//Initialization
NSString
bundleID = [[NSBundle mainBundle]
objectForInfoDictionaryKey:(NSString*)kCFBundleIdentifierKey];
_keychain = [[FXKeychain alloc] initWithService:bundleID accessGroup:nil];
....
//Getting login and pass
return [self.keychain objectForKey:(__bridge id)kSecValueData];
return [self.keychain objectForKey:(__bridge id)kSecAttrAccount];
....
//Setting login and pass
[self.keychain setObject:object forKey:(__bridge id)kSecValueData];
[self.keychain setObject:object forKey:(__bridge id)kSecAttrAccount];

@tomachi

After poking around this issue for a year and nagging Apple Im certain that this issue is related to the keychain and a memory stress on the device. The securityd process is getting killed once there is a memory stress and the app is back to foreground after waiting in the background for some time. The only solution is to kill the app so securityd process will revive itself and connect again to the app and the keychain. Also recommended is to kill all other apps in background in order to remove the stress from device memory. Apple just informed me they are still working on this issue with no luck and they have a security team dedicated to this issue, that was first seen in 2013!
As my app has a very sensitive data and use of keychain is no good i had to use user defaults and encrypt the data by myself. Bad for security, good for happy users.

@SolomonBier

Seeing this as well iOS 9.1, Debug and Release, on iPhone 6

@xilin

@BrightsCode UICKeyChainStore is free of this bug?

@insha

@BrightsCode No. This is not a bug with any wrappers for Keychain as it has been pointed out by Sam and other above. This is an issue/bug with Keychain itself, which Apple has yet to address.

@rsanchezsaez

I wonder how big apps like Tumblr, Pinterest, etc., handle this issue. They never seem to log you out nor crash on launch. Did they implement their own in-app encryption to store credentials?

@abc2mit

@RebornSoul Don't know if this is trolling or what. Can you provide more info? Looking at the source, this doesn't seem much different than SSKeyChain or UICKeyChain, so the issue would be the same.

@RebornSoul

@abc2mit more info on what? You can check their keychain wrapper and see that it doesn't produce any issues. I already migrated when was tired from sskeychain bullshit.

@paulbruneau

You can look at Sam's and see the same thing. But good luck

@abc2mit

@paulbruneau @RebornSoul More info as in, what do you use it for? Why does it work and not the other keychain wrappers? It doesn't look any different source code-wise from the others.

Can someone also take a look at tell us if there's a difference?

@danielgalasko

@RebornSoul This issue has nothing to do with SSKeychain. This is a known bug on iOS keychain. Please consult the official dev forum https://forums.developer.apple.com/thread/4743 this issue will persist irrespective of the library you use, assuming at its core it is interacting with the Keychain API.

@mteece

UICKeyChain suffers from the same issue. We're seeing the same problem with it. Really stems from Keychain. We were hoping iOS 9.2 would resolve it, but no such luck https://forums.developer.apple.com/thread/4743.

@Valpertui

Neither 9.2.1

@ntnmrndn

Same issue here :(

@devValley

Still happens on iOS 9.2, iPhone 6s.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.