Is 1Password data stored securely on the iPhone?

Options
SpringComp
SpringComp
Community Member

I'm sorry if I missed that tiny bit of information in the documentation or on the blog, but I would like to know whether the local copy of the 1Password database - as stored in the underlying filesystem of the iOS device - is indeed encrypted ?

Let's say, should an attacker with specialized skills have access to the iPhone, would he be able to read the 1Password data in clear text or would he find the encrypted version ?

I'm trying to increase my security by applying more stringent protection measures - for instance, by using a long 8-digit PIN instead, by not necessarily have Safari store passwords for the sites I visit, by regularly forgetting public WIFI hotspots before disconnecting, etc. But I would be a bit reassured if the local 1Password data was indeed encrypted...

Comments

  • SpringComp
    SpringComp
    Community Member
    Options

    I should add that, as a software programmer, I attended a conférence about Security. I was shocked to learn that most built in applications on the iPhone store the passwords in clear text as part of their settings.

  • Megan
    Megan
    1Password Alumni
    Options

    Hi @SpringComp‌,

    I am so glad you are thinking carefully about the security of your data - thats what we like to see!

    The short answer is yes. Your data is encrypted when it is stored on your iOS device. :) It is unencrypted, as needed, after you enter your Master Password. It may be worth pointing out that all data on an iOS device is actually hardware encrypted, too. So, your data is encrypted by 1Password, then encrypted again by the iOS.

    If you'd like a few more details, you can see the thoughts behind our data format's design and all sorts of other security-related goodies here:

    http://learn.agilebits.com/1Password4/Security

    Also, you can check out our blog for many more articles that go into the nitty gritty math behind what makes 1Password so secure.

    http://blog.agilebits.com/tag/cryptography_/

    I hope this helps, but we're here if you have any further questions :)

  • SpringComp
    SpringComp
    Community Member
    Options

    Thanks, that clears things up.
    Cheers.

  • Megan
    Megan
    1Password Alumni
    Options

    Hi @SpringComp,

    I'm glad that answered your questions! We're here to help you stay safe out there. :)

  • dbadger
    dbadger
    Community Member
    Options

    Hi Megan,

    That almost answers the question but there's a missing bit :) The encryption that iOS uses for its filesystem is actually relatively easy to bypass (even without a lock code). It exists mainly to facilitate very fast remote wiping of the phone's filesystem in the event of loss (since only the encryption key need be deleted).

    Various tools make it not especially difficult to recover an unencrypted image of the filesystem. (Partly) because of this, Apple introduced a feature called Data Protection that combines your phone's lock code (if you have one) with the phone's filesystem encryption key. This permits the encryption that an application uses for its data storage (apart from the filesystem encryption) to be encrypted in such a way that the device passcode is required to have been entered (that is, the phone cannot be displaying the lock screen) in order for that application's data to be accessed.

    If you use a 4 digit passcode, that's not a lot of extra protection, but phones that use TouchID permit one to use a very nice long passcode while still maintaining the convenience of a short passcode (my phone uses a 19 digit "random" passcode and requires unlocking immediately).

    So the (a) question is: Does the iOS version of 1Password use Data Protection?

    This is actually quite important, as if the answer is yes then someone like myself can use a (somewhat) more convenient 1Password passcode (password entry on a small touch screen is suboptimal and really quite error prone) and rely upon the device for strong encryption. If the answer is no, then one would be strongly advised to use a very strong 1Password passcode and have to go through the hassle of entering something like that each time the app is used.

    Any insight that you (or anyone) could provide would be much appreciated.

    tl;dr: Does 1Password for iOS use Apple's Data Protection feature?

    Thanks! :)

  • Megan
    Megan
    1Password Alumni
    Options

    Hi @dbadger,

    I just wanted to let you know that I've asked our security guru, @jpgoldberg‌ to weigh in with his thoughts here. He'll be able to give you a much better answer than I. ;)

  • dbadger
    dbadger
    Community Member
    Options

    @Megan: Thanks!

  • jpgoldberg
    jpgoldberg
    1Password Alumni
    Options

    Hi @SpringComp‌

    Leaving aside iOS data protection

    First let me leave aside the iOS data protection question and review 1Password's design.

    Your 1Password data on your phone is encrypted by 1Password with your Master Password. This is independent of any data protection provided by the operating system.

    The same, of course, is true for 1Password on all platforms. We designed 1Password with the expectation that people would have their devices and computers stolen in ways that would allow an attacker to read data from the disk.

    I still very strongly encourage people to set device passcodes for their phones in general. Likewise, I believe that full disk encryption (FileVault on OS X, Bitlocker on Windows) is a good option for many people. But 1Password's design is not depending on those.

    How 1Password uses iOS data protection classes

    There is no simple answer to this because we use different data protection classes for different things. For example, we use the iOS keychain to
    store a Dropbox authentication token for fetching and pushing encrypted data to Dropbox. This data fetching and retrieving doesn't need to decrypt your data, so it can happen "in background", and so this token is protected with "CompleteUntilFirstUserAuthentication" and "ThisDeviceOnly".

    ThisDeviceOnly

    We use ThisDeviceOnly for any credentials we store (typically in the iOS keychain), but we have chosen not to do this for the guts of the data. [Note to those who might only have heard of the iOS keychain in terms of Apple's iCloud keychain. The iOS keychain has been around much longer than iCloud keychain, and the things that apps may store in there are not sent through iCloud unless specifically requested.]

    1. Data availability

      If someone has lost or damaged their device, then their 1Password data is one of the first things they will want restored from backup onto
      a replacement device.

    2. Ambiguous security advantages

      Relying on the security of ThisDeviceOnly means not encrypting backups made through iTunes. If you encrypt your iTunes backups
      (and most people should), then data protected with ThisDeviceOnly is no longer encrypted with the device key in the backup, but with a key
      derived from the backup password.

    So because of these, we've decided that the ambiguous advantages ThisDeviceOnly are not sufficient to be worth the more substantial risk of data loss.

    Complete or CompleteUntilFirstUserAuthentication

    Historically and this is reflected in the current version of 1Password on iOS, we've tended to default to "CompleteUntilFirstUserAuthentication" because we wanted to make sure that we could handle "background" synching and fetching smoothly. But as that technology is maturing under-the-hood, we are switching to "Complete" as our default unless there is some good reason to set things otherwise for a file.

    History

    As you may or may not know, one of the big differences between 1Password 3 and 1Password 4 is that we've separated the fetching/pushing to sync servers from integrating those changes with the local database (during which data is decrypted from one data format and re-encrypted for another). This way, 1Password does not need to do stuff with your local database "in background" and so we can both (a) discard encryption keys earlier and (b) shift to using data protection "Complete" for most of your local data.

    tl;dr

    tl;dr: Currently most is CompleteUntilFirstUserAuthentication, but we are shifting to Complete except for where there is a strong reason to do otherwise.

  • chcn
    chcn
    Community Member
    Options

    @jpgoldberg,

    Let me begin by apologizing if anyone is bothered by resurrecting old threads. I've never understood why that bothers some people. If the information is still relevant to other people, does it matter that the OP may not care anymore? But anyway, if it's poor etiquette, please forgive me.

    I am new to this forum and wanted information just like this to help me choose a password manager. Just like @dbadger, I want to be able to use a relatively short passcode on my password manager, knowing that the data is safely encrypted by iOS, but as I understand it this is only true if the software is using the NSFileProtectionComplete data protection class, or at least NSFileProtectionCompleteUnlessOpen or NSFileProtectionCompleteUntilFirstUserAuthentication.

    So, can you please give a quick confirmation/update of your answer above? Is the data that I have entered into 1password protected by iOS data protection? What is the status of shifting to Complete?

    BTW, I recently discovered that the password manager I have been using (SplashID) does not use iOS data protection at all. In particular, a Splash developer told me, "We don’t make use of NSFileProtectionComplete option. That option can be used only if we are using CoreData or NSFileManager class methods. We don’t use either of them." Now, I understand that in iOS 7 Apple changed the default to CompleteUntilFirstUserAuthentication, so that third party apps would use that protection level automatically. But, not being an iOS developer and only partly understanding what the Splash developer told me, I don't know if that means SplashID would now be using CompleteUntilFirstUserAuthentication or still nothing. Thoughts?

  • jpgoldberg
    jpgoldberg
    1Password Alumni
    Options

    Yes, @chcn.

    All 1Password data on iOS is protected with at a minimum of NSFileProtectionCompleteUntilFirstUserAuthentication (Which files use "UntilFirstUserAuth", "UnlessOpen" or simply "Complete" depends on what is needed for background synchronization.) But the short answer is "yes". 1Password makes full use of iOS data protection classes.

    But while we take full advantage of iOS data security, I still do not recommend that you use a weak Master Password. We make use of iOS data protection, but we don't rely on it. Keep in mind that if you create a Master Password along the scheme recommended in Toward Better Master Passwords, you can get a reasonably strong one that isn't too hard to type on an iPhone keyboard. You can also make use of PIN/TouchID unlocking so that you don't have to use your Master Password that often.

    I do recommend that people use at least a 6 digit device passcode for iOS. This is especially true if you are going to be relying on iOS data protection as your primary protection.

  • chcn
    chcn
    Community Member
    Options

    Thanks @jpgoldberg‌!

    Two quick follow-up questions/comments:

    1. Do you have an update on the process to shift more things to "Complete", which you referred to in the last sentence of your May 8 post above? Is the main body of the data now protected by "Complete" most of the time?

    2. I do use a very complex device passcode for iOS. This is the reason I'd like to use/would feel safe using a comparatively weak Master Password for 1password, but only if 1password's data is secured by "Complete". I appreciate your reference to PIN/TouchID unlocking. That prompted me to go read these articles:

    I see how you've worked around Andreas Kurtz's concern by keeping 1password's database encrypted with the Master Password, but this requires storing the Master Password in the keychain, which does seem a little less secure. After reading all of the comments below Shiner's blog post, and reading Hessijames's post and all of the replies, I agree with the folks who say you need to bring back the 5.0 option to expire Touch ID local authentication after a configurable period. That said, if my plan is to use a weak Master Password, maybe it doesn't matter, as long as everything is encrypted with iOS's "Complete" encryption as much of the time as possible. (I would rather sacrifice background syncing and keep it encrypted at all times when the app is not in the foreground. I don't plan to use Dropbox or other cloud syncing anyway. Just local WiFi syncing to my PC.)

    So, can you give more complete/updated information on the status of using "Complete"?

  • MartyS
    MartyS
    Community Member
    edited November 2014
    Options

    Food for thought, @chcn. I'm sure that you've considering all the angles, but if you have a "weak" master password on your iOS device yet feel comforted by all the other answers that @jpgoldberg‌ provides on how 1Password uses that platform's security features, your issue then extends to your PC as well since it will require use of that same master password. Any weak link can and will easily present itself somewhere else if given the chance.

  • MikeT
    edited November 2014
    Options

    Hi guys,

    @chcn,

    I do use a very complex device passcode for iOS. This is the reason I'd like to use/would feel safe using a comparatively weak Master Password for 1password

    You should not use a weak master password at all in 1Password, there is nothing we or anybody else can do to let you use a weak master password while keeping your data safe. If you choose a weak master password, you are risking your data regardless of what kind of other protection you may have on top of it.

    When you choose to use a weak password, you are intentionally weakening the safe in your house and pinning hopes on the front gates to keep you protected. Once someone blows the gate apart, he doesn't have to do much to unlock your safe if it is intentionally weak. It is safer to have a strong gate and a strong safe at the same time.

This discussion has been closed.