Ever since the release of iOS 4, developers have been able to use the Keychain as method to store and secure privileged information for the iPad or iPhone user. That said, iPad and iPhone developers need to be sure that they are well-versed in the options available to store those secret items securely.
Since the release of iOS 4, Keychain items have been able to be stored and protected with as many as two layers of
protection. When implemented properly, the items will be encrypted with a device-specific key as well as a user key which is used to unlock the device.
Should the device be jail-broken, then it is possible to bypass the device key, but not so much with the user key. The user-defined key is variable in strength based on the type of locking pass the user implements. The time it might take to break through a user defined key is shown below.
≈50ms per password try; → ≈20 tries per second; → ≈1.7 years for a 50% change of guessing the correct passcode for a 6-digit alphanumeric code with base 36. The standard simple code of 4 numeric digits would be brute-forced in less than 9 minutes. Based on the assumption that the counter for wrong tries in the iOS can be bypassed, as it is not hardware-based
Source: Apple Inc. WWDC 2010, Core OS, Session 209 “Securing Application Data”, Slide 24
When the device is locked, the extra layer of encryption that Lock Password provides protects Keychain items stored with kSecAttrAccessibleWhenUnlocked or kSecAttrAccessibleWhenUnlockedThisDeviceOnly.
Our iOS development team suggests using those attributes only for the truly sensitive data that you wish to store in the Keychain. Be sure to warn the user concerning the strength of their device lock password and protecting the integrity of the sensitive information stored for your app.
Apple goes even further, and they suggest that developers use a weak derived key for use with background operations. It seems that having them accessible while the device is locked removes some of the security of the information to be stored.
Similar to what we wrote about in yesterday’s SharePoint blog regarding two-step security, the more you make things secure, the more you will likely hear users complaining about how hard it is to use. The reverse, of course, is also true – the less you secure sensitive data, the greater the risk to have users complain about data breaches or worse. As with all things in life, the developer needs to strike a balance between security and accessibility.
Just remember that storing certain secrets in the Keychain, like a username and password combo last used by the user (as a “remember me” feature), may enhance the usability for the user, but it does so at the cost of decreasing the security. No matter what the scenario, there is always some risk of a stored item being exposed by a lapse of security.
You can learn more on this subject by visiting StackOverflow.com at this link – http://stackoverflow.com/questions/3558252/ios-keychain-security.
Let us know how you balance security with accessibility and functionality as you create your apps in the comment section below. We’d love to learn from your experience.