Enforcing master password in iOS keychain

spyder
spyder
Community Member
edited October 2014 in iOS

I have a question about the removal of this option :)

I've always disabled the use of the iOS keychain in 1Password. I understand that it makes the experience less consistent, but this always struck me as a lapse in security - what's the point of a master password if it's going to be stored using a keychain that's only protected by a PIN code? I may as well just use the iOS keychain for everything and abandon 1Password completely?

Comments

  • jpgoldberg
    jpgoldberg
    1Password Alumni
    edited October 2014

    That is an outstanding question, @spyder‌!

    This is not something that we changed lightly; so I'm happy to get the opportunity to explain some of the reasoning that went into this decision. But first some preliminaries:

    1. If you set 1Password to "Always Require Master Password" then all of this is moot. The iOS keychain is only used this way for Quick/PIN/Touch unlock of 1Password.

    2. The Master Password (in obfuscated form) is only stored in the iOS keychain temporarily. Once the "prompt for Master Password" time has elapsed 1Password will remove the item from the keychain. The security risk here is that if 1Password has crashed or the device is shutdown abnormally, it is possible for the data to remain in the keychain longer than intended.

      It is because of that possibility that when we started using the iOS keychain for Quick Unlock/PIN we added the option to turn off that option.

    So what has changed?

    The reasons for having the option haven't gone away, but there are four things that have changed with 1Password 5 on iOS 8 that have tipped the balance.

    1. Quick Unlock/TouchID requires iOS keychain for application extension.

      The big reason behind this change is that unless the MP is stored in the iOS keychain, the 1Password Application Extension would always require the Master Password. Because each instance of the Application Extension is its own process, it can't "keep" the Master Password in memory the way that the 1Password App itself can. The only way to do Quick Unlock/PIN/TouchID for the application extension is with the iOS keychain.

      Quite frankly, people who were saying NO to Use iOS Keychain were becoming very very annoyed with the application extension. We spent a great deal of time looking at how we could alert people to what was going on. We had a big explanatory pop-up in the extension; we had more text on the "Use iOS Extension" option, but these were just confronting people with too much text and making the extension even more annoying.

    2. TouchID on the iPhone 5s and 6 make Quick/Touch unlock a more important feature

      The unreliability of having a PIN/Quick unlock when Store in iOS Keychain was disabled wasn't so noticeable a problem. But with the introduction of TouchID for unlocking, our overall quick unlock became a feature that really needed to work the way that people expected it to.

    3. Keychain item requires that a device passcode be set

      Prior to iOS 8, we had no way to force people who were using the iOS Keychain to have a device passcode set. The idea of having an obfuscated from of the 1Password master keys sitting in an unprotected iOS keychain was not something that we were particularly happy about. This is really why we set up Quick Unlock/PIN to be able to work without using the iOS keychain.

      iOS 8 offers a keychain attribute kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly. This is the attribute that 1Password 5 now uses for this data. So at the very least, the Master Password equivalent that is stored temporarily in the iOS keychain will always be protected by a device passcode. We recommend that people use an at least 6 digit device passcode, but can't enforce that. But now we can at least enforce that one gets set.

    4. Never backed up

      We have long said that your Master Password never leaves your device in any form. A while back in the forums, someone (I think it was @benfdc‌) correctly pointed out that the data stored in the iOS keychain, even with the "ThisDeviceOnly" setting does make it into iCloud backups. The "ThisDeviceOnly" setting means that the data is encrypted with, among other things, the hardware device key that is baked into each iOS device. Yet if Apple isn't being entirely truthful when it says that absolutely no record of those baked in keys exist, then people may still be legitimately concerned about those backups.

      Another feature of kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly is that it truly is never backed up. So it means that we can return to saying "your Master Password never leaves your device encrypted or otherwise".

    The first two of these reasons are positive reasons for eliminating the option. The second two reasons are reasons why using the iOS keychain for this data is less of a concern in iOS 8 than it was in iOS 7.

    I don't expect that everyone will find the combination of all of those reasons sufficient although I am (provisionally) happy with our choice. But those are what has changed in iOS 8 and 1Password 5 that makes us more comfortable with this.

    Nothing is written in stone.

    These sorts of things are never easy decisions. So it is always open to further consideration, and so we all welcome further comment and discussion of this.

  • spyder
    spyder
    Community Member

    Thanks for the detailed explanation. I'm hopefully getting an iPhone 6 soon so I was already thinking I would have to switch to leaving the master password in the keychain more often in order to use Touch ID. It's good to hear things are better with iOS 8.

    I've given this some thought, and I have an idea. It might be a terrible idea, but discussion never hurts!

    I wonder whether there is a way to create something like an app-specific password as used by internet services (in this case a device-specific password). Revoking the password wouldn't prevent access to the local vault, but for someone like me who syncs their vault to dropbox it would mean that in the event of a compromised phone that password couldn't be used to view future changes to my vault. In fact if the hacker forgets to disable sync, as soon as I revoke it the compromised password stops working :)

  • Megan
    Megan
    1Password Alumni

    Hi @spyder‌

    I'm so glad to hear that @jpgoldberg's post helped you out. :) I'll ask him to step in here again to discuss your feature request, I'm sure he'll have plenty of advice here that is completely above my comprehension.

    You're right though, discussion is a wonderful thing!

  • spyder
    spyder
    Community Member
    edited November 2014

    Something that wasn't really clear to me with this change, and I was about to log as a bug, is that between device restarts the PIN code was all I needed to unlock my keychain. I was used to it requiring the full master password after 5-10 minutes. Having re-read the security page text I see this is intentional.

    Now that I have my iPhone 6, I can accept that Touch ID is secure enough to not need a timeout back to master password (other than device restart), but having just a 4 digit PIN code to unlock my keychain made me a bit nervous (despite needing to enter the phone PIN first).

  • Drew_AG
    Drew_AG
    1Password Alumni

    Hi @spyder,

    I'm glad you were able to find your answer on the security page. Just to add a bit of information, I wanted to let you know that when using Touch ID (or the PIN code) in 1Password, you'll still be asked for your master password in these circumstances:

    • You restart the device.
    • You enter a wrong PIN code / Touch ID fails (or you tap Cancel on the Touch ID screen).
    • You use the Lock Now option in the Security settings of 1Password.

    If you have more questions or concerns, please let us know! :smiley:

This discussion has been closed.