1. Add lock code to your phone
2. Open the app without a debugger attached and start monitoring for significant location changes
3. Minimize app
4. Turn off iPhone
5. Turn iPhone back on.
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.
Now to know when the app actually wakes up while you'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.
Hope that helps everyone else!
If we had known that the bug was caused by reboots though, we probably would have saved some gas as well.
By the way, in general this isn't a reboot specific bug, the most secure setting is actually not the "allow after unlock" one but the one that gives no access to keychain if your phone is locked at any time. I noticed that keychain starts refusing access 15 seconds after you lock the phone but most apps keep their credentials in memory after they're read and the problem appears at reboots only.
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's a session cookie.
kSecAttrAccessibleAlways
The data in the keychain item can always be accessed regardless of whether
the device is locked. This is not recommended for application use. Items
with this attribute migrate to a new device when using encrypted backups.
Consider, for example, iCloud backups. The "kSecAttrAccessibleAlways" data may be encrypted, but its with a key that Apple knows. So using kSecAttrAccessibleAlways sounds a lot like how Google backups store your WiFi password.
As 'itsboncheck' mentions down-thread, a better choice (still a serious compromise) may be...
kSecAttrAccessibleAfterFirstUnlock
The data in the keychain item cannot be accessed after a restart until
the device has been unlocked once by the user. After the first unlock,
the data remains accessible until the next restart. This is recommended
for items that need to be accessed by background applications. Items
with this attribute migrate to a new device when using encrypted backups.
Storing a token in the keychain is preferable, because revoking a token is less onerous than nuking a user's password. Keeping the security set to maximum (kSecAttrAccessibleWhenUnlockedThisDeviceOnly) also seems advisable when we're talking about user password, or even access tokens. Just defer the backup task until the device is unlocked.
If you absolutely must proceed with the background task while locked, consider issuing a less-trusted token which is ONLY used for background tasks, and provide the absolute least privileges possible to accomplish the background task when presented with that token.
Also consider rotating it. For example, whenever a user connects with their full-access token, indicating their device is unlocked, it's a good time to expire the old background-task token and provide a new one. This also lets you do a "mass delete" of existing tokens in case of any funny business, and you'll have automatic recovery ("background processing will start working again next time you unlock").
From what I remember, no, they definitely don't save it in plaintext.
It's late, and I don't remember the exact details, but there are places where Apple talks about how it works.
Here's the gist, I think: When the user unlocks the phone, several encryption keys are generated using the pass code. One's used for Available After First Unlock, and that one's stored in RAM till the device reboots. Another is used for items that are only available when unlocked, and that's thrown away every time the phone is locked. Items that are restricted to the device use a key that is also derived from a private device identifier.
So not plaintext, but the decryption key is hanging around in the device.
You're definitely on target with the suggestion for a background task token though.
Just pause the startup process of the app (in a non-blocking way) if accessing the keychain fails at startup. Then during applicationDidBecomeActive the startup continues with access to the keychain data. That way we don't weaken the security of our customers.
It's a trade-off between user experience and security. As soon as Apple fixes the reboot issue, we'll increase the security level back to kSecAttrAccessibleAfterFirstUnlock.
I'm pretty sure that's only true for non-Jailbroken devices.
I agree with zaroth here: don'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.
That's what the presenter in the session has recommended too.
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'm not sure how I never came across kSecAttrAccessibleAlwaysThisDeviceOnly in all my hours trying to find a solution.
By the way, this isn't specific to iOS 7. I've had the same issue since iOS 5.
I hope a follow up post discusses how they removed this "feature" and took advantage of the new API for background updates.
As a user, and an iOS developer, I'm excited to have a supported, battery-friendly (intelligent?) system for allowing frequently used apps to update in the background. And this seems like a good fit.
New OS updates introduce weird bugs that require hacky code to get around. Early adopters will always update to them and then complain to you that your app is broken, making the hacky code required.