Questions regarding 1Password 4.5's use of the iOS keychain for Master Password

Megan

Hi @benfdc,

We do our best to be transparent wherever possible (I think that's an important quality for a security firm to possess).

However, in this case, I'm not quite sure what you're looking for. Are you concerned about someone else obtaining your keychain from your Dropbox account? Because vaults are synced individually, if you are particularly cautious about a particular vault, you can leave it unsynced to ensure it remains only on your computer.

I know this isn't the answer that you're looking for, but I'd be very interested to hear a bit more detail about how this would be valuable to you, and perhaps how you see such a thing implemented.

jpgoldberg

@benfdc‌ noted:

I think that this sort of thing [keys for secondary vaults stored in the primary] should be transparent to the user. I should be able to manage the information stored in my keychain, and I cannot manage what I cannot see.

I agree. But it may be quite a while before this gets implemented. The keys for other vaults are really just special items in your primary vault, but at this time we provide no interface for seeing them or deleting them. (We really wouldn't want people to be able to actually edit them, as the data in these special items is very specifically crafted.

benfdc

To be clear, I am not suggesting that the UI should ever disclose a stored master password to the user. Been there, done that, not fun. In this context, “see” means detect and “manage” means delete.

If it will be a while before the 1Password apps will be more transparent on this point, I would suggest that the user documentation be updated to make very clear that if 1Password’s multiple vault feature is employed, the master password to any and all secondary vaults will sync off of the user’s device.

Also, if it hasn’t been covered already, the documentation should discuss how to handle a situation where the invisibly stored password to a secondary vault becomes stale (because the password to that vault has been changed). For that matter, I am not certain that changing the password to a secondary vault would prevent my iPhone from opening it. That would depend on whether what is being stored in the keychain is the master password to the secondary vault or the master encryption keys to that vault, and I have no idea which is the case!

MikeT

Hi @benfdc,

To be clear, I am not suggesting that the UI should ever disclose a stored master password to the user. Been there, done that, not fun. In this context, “see” means detect and “manage” means delete.

We've gotten a lot of requests to be able to manage the vaults directly, like renaming the titles, colors, icons, as well as managing the passwords. Goldberg's idea would go into this as well. In such a manager, we could add an option to Do not automatically unlock this vault when primary vault is unlocked or something like that.

If it will be a while before the 1Password apps will be more transparent on this point, I would suggest that the user documentation be updated to make very clear that if 1Password’s multiple vault feature is employed, the master password to any and all secondary vaults will sync off of the user’s device.

We're updating and overhauling the security docs to move it to our new docs platform on Manula. I'll make sure the docs team take your suggestions in place when updating the security docs as well.

For that matter, I am not certain that changing the password to a secondary vault would prevent my iPhone from opening it.

It would be the encryption key, in which case, changing your master password would not change anything. We probably would change how this would work in the future to require changing the master password to re-encrypt the vault as we continue to move toward the future where mobile devices are far more capable.

MikeT

@benfdc,

Just to be clear on this:

Related: If I establish a connection to a secondary vault on my iPhone, can that be detected by analyzing the primary vault on my Mac?

None of the information about secondary vaults ever leave the local database. In other words, it does not get exported to the sync files that syncs to other devices.

If you're syncing both primary/secondary vaults from Mac A to Mac B, when you double-click on secondary vault to add it to the 1Password database on Mac B, you will be required to enter the vault password regardless of your Mac A's database knowing about this vault. That information is simply not synced.

If however, you copy your local 1Password database files to Mac B, then yes, logically, it will know about secondary vault because you've copied over the database file which includes all of the vaults you've added and its keys.

I'll add this to the docs.

internal reference number: DOCS-161

benfdc

@MikeT—

I am now extremely confused. @Megan wrote in #30 above that

The Master Passwords for secondary vaults are stored in within the database of the primary vault.

And @jpgoldberg wrote in #33 that

The keys for other vaults are really just special items in your primary vault,

Is there a distinction between “the database of the primary vault” and “the primary vault”? Was Jeff being imprecise in #30 with the term “primary vault”? You write about Mac A and Mac B, but this thread is in the 1P/iOS forum. Are there implementation differences between platforms that are relevant to my concerns?

Megan

Hi @benfdc,

I apologize for the confusion here! My explanation of the way secondary vaults are handled was slightly simplified. Since @jpgoldberg‌ is our resident security guru and Defender Against the Dark Arts, I think it's best if I let him answer your questions directly, so that we don't confuse things further.

benfdc

@Megan—

Before this is over, somebody will explain what is going on in language that I can understand. Of that I have no doubt. It’s what you folks do so well, and it is why I am so loyal to the product notwithstanding all of the issues that I raise here in the forums.

jpgoldberg

As you, @benfdc‌, note, we haven't not settled on terminology about many of these things. (Look at how long it took to start using "opvault" when the first documents called it "the 1Password 4 Cloud Keychain Format").

Most people will think of their "vault" as the set of information that they have added and can manipulate. But when we talk about the finer points of what is going on we need to distinguish between the "local format" (SQLite on OS X and iOS) and the sync format (Agile Keychain or opvault). The keys for secondary vaults are stored only in the local data and are not included in the sync formats.

I was trying (and failing) to say something that I wouldn't have to back peddle on. The result was my playing with words that only made matters worse.

Anyway, one of the problems we face in this business is that we will want to use the word "vault" to refer to a particular set of user data. This is, after all, how most people will think of it. Furthermore, the local format is largely invisible to people. You really have to go hunting for it. The "exported sync formats" are far more visible. And so those are what people will think of as their vaults when they think in terms of files. And of course, this distinction between "sync format" and "local format" is new in 1Password 4 for Mac. So those who have used 1Password 3 on the Mac will very naturally think of their vault as the Agile Keychain Folder/File. (The distinction has actually been in 1Password for iOS since the beginning, and the distinction does not exist for 1Password for Windows.)

To add to the complexity is the fact that vaults are stored within the same SQLite database. So there isn't a separate file for vaults within the local data.

If we try to be fully precise in all of our language and come up with expressions for each of these notions of "vault" we may not be able to communicate effectively to most people. (An analogy is that we talk about people's data being encrypted with their Master Passwords. This, on the whole, is better than saying "your data is encrypted with randomly chosen item keys that are in turn encrypted with a master key which is encrypted with a key derived from the Master Password." But as you well know, "encrypted with Master Password" implies forward secrecy on a Master Password change, and so there are times well people need to know the fuller story.)

Once we actually have to talk about how keys for secondary vaults are stored in primary vaults these sorts of distinctions get confusing. And, to top it off, we haven't internally settled on terminology. Another place where these subtleties show up is in understanding how a Master Password change propagates across systems.

jpgoldberg

Anyway, within your local data (SQLite format) and protected (through a chain of keys) by your primary vault Master Password are the actual encryption keys of secondary vaults and the encryption keys for the formats you sync with.

Let me clarify that second example. As you (but perhaps not everyone reading this) know, the actual encryption keys for the Agile Keychain are not the same kinds of beasts as the encryption keys that are used in the 1Password 4 local format and .opvault. Leaving aside security levels, MAC keys and some tricks we use to compensate for potentially biased system RNGs, the master key for an Agile Keychain is a 128 bit AES key. Everywhere else it is a 256-bit AES key. Also in the Agile Keychain, key derivation uses PBKDF2-HMAC-SHA1. For .opvault and the local data it uses PBKDF2-HMAC-SHA512.

Now we want synching between the local data and your Agile Keychain to be seamless. We want to "unlock" your Agile Keychain as soon as you unlock your local data. One option would be to run through the full key derivation for both formats to derive the keys needed for each. But because we want the formats that are used for synching to have the strongest cracker resistance, this would be really expensive to do (particularly on iOS). So instead, once we run through key derivation on a sync format, we save the keys within the local format data.

Those keys become available once you unlock your primary vault. But those keys are never included in an Agile Keychain or opvault. And, as you note, their existence isn't even visible to the user. So it becomes a matter of tricky (and somewhat arbitrary) definition to say that those keys are "in the primary vault" or not.

benfdc

Jeff, I am not following every detail, but I think that you have covered all of my concerns. Many thanks for taking the time to lay this out.

So, on to the next question! Given the distinction that you have now made clear between sync formats (opvault and Agile Keychain) and local formats on iOS and OS X (SQLite), what goes onto my Mac when I back up my iPhone via iTunes? And what would go into iCloud if I were to enable iCloud backup?

steven1

In light of recent iCloud hacks, want to ask benfdc's question again:

since the ios keychain gets backed up to the iCloud if you have icloud backup of your ios device enabled, how easy is it to extract one's master password if the attacker is able (through the numerous ways discussed in the press) to get a copy of the device backup?

Is it still a good idea to save your master password in the ios keychain?

How will the version for iOS 8 change this when it uses the secure enclave / touch ID?

Thanks!

Jasper

Hi @steven1,

We take several steps to ensure your Master Password is stored securely in the iOS keychain, even when it is being backed up to the cloud.

We use the kSecAttrAccessibleWhenUnlockedThisDeviceOnly protection class for the Master Password stored in the iOS Keychain. This means your Master Password in the Keychain is protected with your device passcode and protected with a device secret.

Every iOS device comes with a built-in unique hardware secret from the factory, only known to that device. With the kSecAttrAccessibleWhenUnlockedThisDeviceOnly attribute, the value stored in the Keychain cannot be decrypted unless you are performing the decryption operation on that device itself. If the Keychain is removed from your device, your stored Master Password cannot be decrypted.

We also obfuscate the Master Password before storing it in the iOS Keychain, but obfuscation is not a perfect solution (it's possible that someone will be able to reverse engineer our obfuscation eventually).

How will the version for iOS 8 change this when it uses the secure enclave / touch ID?

The iPhone 5s (and iPhone 6 and 6 Plus) use the Secure Enclave to perform the decryption of the stored Master Password. In this case, 1Password sends a request to access your (obfuscated) Master Password from the Keychain, and the Keychain then sends the encrypted item to the Secure Enclave, where it is decrypted, then returned to 1Password.

There will also be changes coming in iOS 8. Some new, interesting things include kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly and LocalAuthentication, but I don't have anything to share about that at the moment.

Please let us know if you have any other questions. We're always happy to help!

jpgoldberg

Let me add one clarification to @JasperP‌'s answer to @steven1's excellent question.

As Jasper explained the "ThisDeviceOnly" attribute on a keychain item means that it can only be decrypted if it is restored to the same device it originated on. I want to point out that "ThisDeviceOnly" is what we've been using with these keychain items from the outset.

Starting with iOS 8 there is also the "WhenUnlocked" option. With this, the item can only be created when a device passcode is set and it will be destroyed if the owner of the device turns off passcode protection. On top of this, these items are not backed up. So with iOS 8, there is even more protection, but the "ThisDeviceOnly" setting does what we need for versions prior to iOS 8.

steven1

Thank you @jpgoldberg‌ and @jasperp.

This makes sense...touch ID enabled ios devices running ios 8 get the greatest benefits from this update in both security as well as balanced convenience!

Even though I haven't turned on the save to iOS keychain option yet, i am finding that the app is not getting killed as often anyway.

However, since it appears that
kSecAttrAccessibleWhenUnlockedThisDeviceOnly has been deprecated in iOS 8 and replaced by
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
, the latter which does not allow it to be backed up at all, I will enable it :-)

Thanks guys! Fantastic upgrade!!

Megan

Hi @steven1,

I'm so glad to hear that @JasperP and @jpgoldberg‌'s posts helped you out! I'll admit, I learned a bunch from reading it as well. ;)

Thanks for your kind words - if you have any further questions, you know where to find us!

steven1

@jpgoldberg I was able to verify that the saved master password did indeed get cleared when I removed my device passcode. However, 1pw still gave me the option to use a QUC with a PIN. It still also had the save to iOS Keychain option.

Question: what Keychain data protection level is used in iOS 8 if the user does not have a passcode on the device?

With iOS 8, I would have thought Save to iOS keychain would have been disabled on a device with no passcode....

steven1

Interesting :0) Maybe I didn't pay enough attention, or maybe it needed a device reboot, but clearly people are complaining that save to iOS keychain is not enabled without a passcode set.

I hope people realize how powerful this attribute is, and set even a simple passcode.

So....is kSecAttrAccessibleWhenUnlockedThisDeviceOnly truly deprecated?

I sincerely hope agile bits continue to use kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly.

Thanks,

jpgoldberg

Hi @steven1,

As you correctly note,

kSecAttrAccessibleWhenUnlockedThisDeviceOnly has been deprecated in iOS 8 and replaced by kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly , the latter which does not allow it to be backed up at all

In once sense this non-backup shouldn't make a big difference because the "ThisDeviceOnly" still means that it can only be decrypted on the device itself. But, like you, many people are more comfortable with it really never leaving the device.

An even nicer feature of kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly is that the item will be destroyed if the user unsets the passcode. So it doesn't just rely on the passcode being set when the item is first saved, it ensures that the keychain item is always passcode protected.

archagon

I was under the impression that the master password was never saved anywhere — exactly the behavior I wanted. However, in the release notes of a recent version of 1Password, I noticed a comment about how the password would be saved to your keychain if TouchID is enabled. How does this work? In what form is the password saved? Does the keychain ever get synced over the network? And is it possible to completely opt out of this behavior? My 1Password cache contains some very important information, and so I absolutely cannot risk my master password getting out anywhere. I don't even write it down on paper, let alone save it to a file on my system!

(Now I'm not even updating out of fear that in the time between I update and disable the feature, my password will end up on the network somewhere.)

EDIT: http://aws.cachefly.net/1Password3/finding_master_password.html If I'm reading this right, it's pretty scary, because it effectively means that your master password is only as strong as the password for your keychain! How can I set up 1Password in a way that ensures that my master password is never saved anywhere, ever, and clears any existing caches?

EDIT 2: Saw the explanation provided here, which has assuaged my fears a bit. However, I want to make absolutely, 100% sure that the master password, obfuscated or otherwise, is never synced over the network (especially with the latest changes in iOS8), and that toggling the "Keychain" setting in Advanced will completely disable this and any other caching behavior related to the master password.

Megan

Hi @archagon‌,

Just to keep the conversation all in one place, I've moved your post into the thread that you were referencing.

I'm so glad to hear you were able to find an explanation that calmed your fears a little bit. Does Jasper's post later in the discussion calm your fears any further?

Tor Arne Vestbø

So from what I've gathered you store an obfuscated version of the master password in the keychain. In the explanation here it says that it's only stored temporarily, and will be wiped from the iOS keychain after the "lock after" timeout.

But with Touch ID in iOS 8 and 1Password 5.1.2, with "Lock on Exit" enabled and "Auto lock" set to 1 minute, it still says "Touch ID will be required every time you leave the app or after 1 minute of being unused". It doesn't say that it will require my master password. However, it says that "Your Master Password will be required after a device restarts or when Touch ID authentication fails".

Does that mean that the obfuscated version of my master password stays in the iOS keychain more or less for the entire time the device is on (if I've entered it once after rebooting)? If so the "risk" is that: "an attacker manages to (a) unlock the phone, (b) jailbreaking the device (so that something other than the 1Password app can get at keychain data that belongs to 1Password, and (c) defeating our obfuscation of the Master Password."

At what time in the reboot process is the master password cleared from the keychain? If it happens on startup the jailbreak could potentially intercept the boot process at such an early stage that it can stop the master password from being wiped?

Ben

Does that mean that the obfuscated version of my master password stays in the iOS keychain more or less for the entire time the device is on (if I've entered it once after rebooting)?

Yes, unless Touch ID fails or you cancel the prompt for Touch ID (which counts as a failure) within 1P. That causes the Master Password to be wiped as well.

At what time in the reboot process is the master password cleared from the keychain?

My understanding is that this happens when the device is shutting down.