How we fixed the iOS7 forced logout bug that's been affecting so many apps

This is not the proper solution. Instead of making your data accessible when the device is locked you should listen for UIApplicationProtectedDataWillBecomeUnavailable and UIApplicationProtectedDataDidBecomeAvailable. Once your keychain item becomes available again you can log the user back in. The keychain will always be available in the foreground.

At Couple, we found a much simpler solution to debug this exact same bug two days ago, and there was no driving needed:<p>1. Add lock code to your phone<p>2. Open the app without a debugger attached and start monitoring for significant location changes<p>3. Minimize app<p>4. Turn off iPhone<p>5. Turn iPhone back on.<p>Now if you wait 3-5 minutes in the same spot, your app will be woken up and will get a significant location change. Much simpler than driving and easily reproducible in the office.<p>Now to know when the app actually wakes up while you&#x27;re in the lock screen, I added a local notification as part of the startup process. Now we just keep the phone locked for a few minutes until it shows the local notification, then you unlock it and see the logout problem.<p>Hope that helps everyone else!

The workaround is to allow access to the keychain data while the phone is locked? I assume the Loom keychain data (including the users password) is only accessible to the Loom app, just now it&#x27;s accessible to the app even if the phone is locked. Doesn&#x27;t give me a warm and fuzzy feeling.<p>Why not store username and a random token in the keychain instead of the actual password? You create the token on a valid login and keep it on the server and in the keychain. Basically it&#x27;s a session cookie.

I faintly remember the WWDC session (I wasn&#x27;t there. I only watched the videos) about background launching to talk about this exact issue. I also remember thinking that this is going to bite people.<p>I agree with zaroth here: don&#x27;t downgrade the keychain security for the password. Either do nothing if the phone is not authorized or store a token in more accessible security levels.<p>That&#x27;s what the presenter in the session has recommended too.

If you need keychain access while the device is locked, using &quot;kSecAttrAccessibleAfterFirstUnlock&quot; is definitely recommended over &quot;kSecAttrAccessibleAlways.&quot; I don&#x27;t remember where I heard this (possibly a WWDC video), but I think most attack vectors require the phone to be restarted to work. Maybe someone with more knowledge on iOS security can chime in with details.

Oh man. I seriously love you. I&#x27;ve been trying to find a fix for this for about two years now.<p>My app sometimes launches from the background after the user enters or leaves a region. It looks for a session token (not a password) in the Keychain and would return nil and log the user out. I&#x27;m not sure how I never came across kSecAttrAccessibleAlwaysThisDeviceOnly in all my hours trying to find a solution.<p>By the way, this isn&#x27;t specific to iOS 7. I&#x27;ve had the same issue since iOS 5.

I have a problem with the downgraded protection on the password, but the abuse of significant location change notifications to start background http requests bothers me a lot more.<p>I hope a follow up post discusses how they removed this &quot;feature&quot; and took advantage of the new API for background updates.

Is there no way to put iOS devices into a debug mode and send fake location data? Android has supported that for a while, and it&#x27;s much nicer than actually driving around.

Interesting. I&#x27;ve been having this issue with SnapChat recently. It no longer remembers my login. I assumed it was just an issue with the app and not something bigger.

If someone presented this fix on my team they&#x27;d be fired.