Keychain Error -34018

This happens infrequently. I'm on iOS 9 testing with an iPhone 6. I found some old threads on this. It's an undocumented error. I remember getting this awhile ago in a different app. It would be very bad for me if this happpened in a production release.


Any ideas?

Replies

This thread has the most up-to-date information (such as it is)-: about the -34018 issue.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Happens in production.

Not solved yet (per Apple from last week).

Thanks for the link Quinn. And thanks for the info Noami. Not sure why I couldn't find that thread when I searched the forums.


I just Developer rejected an app since it happens in production. I don't want to get bombarded with one star reviews.

Sorry for the delay Macho Man ***** Savage. So what is your solution?

Rejecting the app will only prevent more users from hitting you, but what are you gonna do regarding the remaining ones?

I had to downgrade my security a little bit and I store my credentials in a plist file where all values are AES-128 encrypred, keys are obfuscated and the encryption key is built in runtime dynamically using obfuscation, keys appending, class names taken on runtime etc.

Not as safe as the keychain but I can't afford loosing more clients as this issue is VERY big and is not gonna be solved in the near future from where I can see it.

I ended up storing the data in a manner that isn't secure. I used the keychain in this particular case to store a flag for an in-App purchase.


It's easier now for pirates to get the iAP for free, but it is better than have paying customers leave 1 star reviews because the keychain failed. Since this isn't a user's password or anything sensitive, I can live with it though I wished the API worked.

Did you at least encrypt your value in the un-secure folder?

You can even hash it and check the value in runtime. If someone will change your hash it will not work and you'll know someone played with it.

I suggest building some kind of an obfuscated string in runtime (don't save it as a string in your code) and hash it, then save it to your user defaults. everytime you want to check the iAP first check the integrity of that string.