Keychain Developer Tip

January 8th, 2007

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.

5 Responses to “Keychain Developer Tip”

  1. rentzsch Says:

    I love photoshopped dialogs ;-)

  2. Daniel Jalkut Says:

    nothing but the best for my readers :)

  3. Mark Grimes Says:

    At least this approach stops with Tiger though. This is largely alleviated in Leopard due to what Perry discussed @ WWDC. In fact, due to the nimble, small development community in Mac-space versus Windows-space one would think that Perry’s work along with the stuff from TrustedBSD will allow a nice authz framework for application launching such that in such an environment rogue applications won’t be plausible, implementation flaws aside. Of course this assumes everyone embraces the offerings from the Data Security group. But yes, I welcome it for the annoying reasons described in your post :)

  4. Evan Schoenberg Says:

    Oh, thank God. I hadn’t noticed that before, either.. I’ve just been clicking through the keychain permission dialogue with every new Adium build (as passwords are accessed to connect) for years. Pays to investigate!

  5. Dorian Johnson Says:

    Thank you so much. As with Evan, I’d been clicking through that damn dialog for every build of CoRD.

Comments are Closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.