First of all, if you’re dealing with any sensitive information on behalf of the user, you’re ethically responsible for storing that information securely. Mac OS X’s deeply integrated Keychain Services leaves you with no excuse for saving passwords, credit card numbers, or other sensitive information in plain-text format on the user’s disk. Access to items in the keychain is controlled by users, and when any new application asks for access, the user generally has to approve it:

I recently added Keychain Support to an application where the sensitive password information needs to be fetched at launch-time, every time it launches. That’s fine, but one of the important security features of Keychain Services is its ability to detect changed copies of a previously permitted application. This is to ward off abuses in case a hacker has replaced some trusted application with one that is programmed to siphon off your keychain passwords or something:

Usually this dialog appears only once in a while, after updating an application to a newer version, or installing an Apple software update. But when you consider the product development cycle: develop -> build -> test, you can imagine how frequently an application under development will trigger this warning.

Until provoked by this nuisance, I didn’t know about a feature in Keychain Access that allows users to open up access to a particular key. In general this would be a pretty insecure choice, but it makes a lot of sense for development purposes:

You’ll find the option in the “Access Control” tab after double-clicking any keychain item. So for the purposes of development, test against a key that doesn’t actually have any sensitive information in it, and set the access to unrestricted. Now you can rebuild and test as often as you like without being pestered by Keychain Services.

This entry was posted to Apple, Carbon, Cocoa, Technology. Comments are closed. Thanks for reading!