1Password 3 for iOS stored Master Password in iOS keychain (when automatic Dropbox syncing enabled)
My wife has both 1Password for iPad (1P3) and 1Password (1P4) on her iPad 2. I have both 1Password Pro (1P3) and 1P4 on my iPhone 4S. My wife's MacBook, which runs OS X 10.7.5 because it is too old for Mountain Lion, has both 1P3.8 (family license) and 1P3.9 (App Store license) installed. She uses Dropbox to sync her keychain between devices, as do I.
We wanted to put copies of our keychains onto each other's mobile devices before 1P3 Dropbox sync died on September 1, and naturally procrastinated until the evening of August 31 was upon us. My wife was able to sync her keychain to 1Password Pro on my phone with ease. I was able to sync my keychain to 1Password for iPad on her tablet, but not without difficulty, and something very bad happened along the way.
My wife had had her keychain both in 1P3 and 1P4 on her iPad, although Dropbox sync had been turned off in 1P3. I deleted 1P3 from her tablet in order to remove all associated data. My intention had been to re-download 1Password for iPad from the App Store, but the app did not appear in her "Purchased" list. I resorted to Plan B, installing 1Password for iPad to her tablet via USB sync from iTunes on her MacBook. The app appeared on her iPad, and I disconnected the sync cable. So far, so good, or so I thought.
I launched 1Password for iPad and was prompted to create a keychain or sync to an existing keychain via Wi-Fi. I opted to create a new keychain, and then tried to sync it to my Dropbox account. The sync failed when 1P3 rejected the password I had entered into 1Password for iPad as the master password for the keychain on my Mac. 1P3 then offered to show me the password, and when I said yes it displayed an unfamiliar pass phrase.
I tried to sync a second time, and this time it worked, with my entire keychain (1200+ items) making its way onto my wife's iPad several minutes before the clock struck twelve. I then told my wife about the pass phrase I had seen, and (as I feared) it was indeed the master password that she has used for her 1Password keychain these last several years.
She is quite unhappy about the situation, and so am I. How could this have happened, and how can your users defend against it?
Comments
-
I'm not sure that I follow the entire chain of events there, but 1P3 for iOS, when set up for automated synching does store a copy of the Master Password in the iOS keychain, so that will be the source of this "exposure". One of the reasons why 1Password 4 on iOS uses the same Master Password as is used for the data on Dropbox/iCloud is so that we don't have to store such secrets in the iOS keychain.
When 1Password was removed from the iPad, all of the app specific data, including that which was in the iOS keychain should be been destroyed. So the data was restored from an that iTunes backup. In this case, you've run into a nasty subtlety about iTunes backups.
1Password 3 for iOS actually sets iOS keychain parameter, thisDeviceOnly, on this data stops it from being available from backups. However that only stops it from being available in unencrypted iTunes backups. In more recent (October 2012) documentation (PDF) Apple has also started to call such items "non-migratory" and has clarified what is going on. It also looks like they changed things (or that previous descriptions, including my own, were wrong), and that non-migratory items remain non-migratory even in encrypted backups:
As explained earlier, non-migratory keychain items remain wrapped with the UID-derived key, allowing them to be restored to the device they were originally backed up from, but rendering them inaccessible on a different device. [...]
>
If a user chooses to not encrypt an iTunes backup, the backup files are not encrypted regardless of their Data Protection class, but the keychain remains protected with a UID-derived key.
So now non-migratory items will always be backed up and will always be encrypted with the device key, whether or not the iOS backup is encrypted. Thus, these are available if restored to the same iOS device they were created on.
At any rate the complexity and subtleties of all of this is one of several reasons why we are relying less on the iOS keychain for important secrets in 1Password 4. But a side effect of that is that you need to have 1Password unlocked for synching to occur and you need to use the same Master Password across devices. (File transfer to and from sync systems can happen with the 1Password is locked, but actual import and export from those by 1Password 4 requires 1Password to be unlocked.)
I'm not sure of the circumstances in which you would actually be prompted to see the Master Password. But because the Master Password was stored for iOS synching, and because the backups were iTunes encrypted backups, that data did become available to an unlocked 1Password once restored from such a back up.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
Jeff—
Thanks for the reply. I figured that the password probably came from iTunes, but I never restored anything to my wife's iPad from a backup (as I understand that term). It seems to me that, if I had done that, her keychain would have been restored as well, and the whole point of deleting 1Password for iPad in the first place was to get rid of her keychain so that I could install mine.
What I did (as best as I can recall) was:
- Deleted 1Password for iPad from my wife's iPad 2
- Tried to reinstall from App Store but was unable to locate the app in the Purchased list
- Launched iTunes in wife's user account on wife's MacBook
- Selected Apps in the iTunes sidebar and confirmed that both 1Password for iPad and 1Password (1P4/iOS) were present
- Selected Updates on the ribbon, or whatever you call that band across the top
- Clicked the Update All Apps button, then watched paint dry
- Plugged the iPad 2 into the MacBook
- Selected the iPad in the iTunes sidebar
Chose Apps in the ribbon, found 1Password for iPad, clicked Install, then clicked Apply
- This may have been a mistake because the iPad, which had not been backed up in months, had not yet finished syncing purchased apps
Got the dreaded iTunes cannot sync apps to iPad "ipadName" because the apps installed on the iPad could not be determined error
- Did some research, ejected the iPad, reconnected it, watched paint dry until sync was completed
- Chose Apps in the ribbon, found 1Password for iPad, clicked Install, then clicked Apply
- Waited for 1Password to appear on iPad, launched it, created new keychain with arbitrary password, tried to set up Dropbox sync, and discovered that I had forgotten the arbitrary password
- Deleted 1Password for iPad from iPad 2
- Re-installed from iTunes
- Wrote down arbitrary password, launched 1Password, opened new keychain with arbitrary password that I had written down
- Set up Dropbox sync to my dropbox
- Got the error message concerning wrong Mac keychain password, then was asked if I wanted to see the password, whereupon my wife's passphrase was displayed to me
- Quit and relaunched 1Password, successfully synced to my keychain via Dropbox
- Waited nervously for sync to complete as the minutes ticked down to midnight
- Reset 1Password for iPad unlock password
FWIW, my wife does not encrypt her iPad backups.
In addition to getting a better understanding of what went wrong on the evening of August 31, I would like to better understand what you just wrote about unlocking and syncing.
- Does this apply only to 1P4/iOS?
- Does it apply when syncing via Dropbox, via iCloud, or both?
- What is the practical significance—how does it affect the user, and what can/should the user do to avoid being tripped up?
- Is it documented? If so, where?
0 -
I'm guessing that the the installation of 1P3 via iTunes is where that keychain restore came from, and that such a reinstallation will restore keychain data, but not app data. (It may be that the keychain data is never removed, it's just that it can't be accessed by anything other than 1Password, so it is "as good as destroyed" when 1Password is removed. However, as noted, that might not really be "as good as" when it comes to the app being reinstalled).
The best documentation on iOS keybags and keychains is that Apple PDF I linked to. It doesn't, however, completely jive with account we'd written up years ago based on an Elcomsoft analysis.
Here is the the documentation for our use of the iOS Keychain in 1Password 3, and this is also discussed in an ancient blog post as well. As noted, I either got some of that wrong or iOS data protection and backups have changed. (I think it is a bit of both. These things were always backed up, but protected with the device key; but now the device key protection is also there for encrypted backups as well.)
1Password 4
In 1Password 4, the iOS keychain is only used for sync credentials and for the Quick Unlock Code.
One of the security changes in 1Password 4 is that other than sync credentials (and the QUC) we don't rely on the iOS Keychain. This changes how automatic sync works for people between 1Password 3 and 1Password 4
In 1Password 4 you need to use the same Master Password across devices
In 1Password 3 you could have different Master Passwords and synching specifically because your "cloud" Master Password was stored by 1Password on iOS (if you set up synching).
In 1Password 4 only some of the synchronization process can happen in the background.
Data files can be copied to and from sync services without 1Password being unlocked, but the things in those files cannot be decrypted. This means that they can't be "translated" from one format to another (which requires decryption and reencryption).
This, by the way, is one of the reasons that the old style of WiFi sync can't be used with 1Password 4. 1Password needs to be unlocked for synching to occur, and we can't unlock it without the Master Password.
With iCloud synching, the file transfer happens independently of 1Password, so the data is almost always already in the right place. This way synching is fairly quick once 1Password is unlocked. That is once unlocked, all 1Password needs to do is identify which items need updating and then "translating" those items. The file transfer between device and cloud has already happened.
0 -
Jeff—
Somebody changed the title of this thread to something very misleading. My complaint is about disclosure, not storage.
What happened to me on August 31 raises a number of questions. The two most obvious questions are:
- Why was the master password to my wife’s keychain still on her iPad after I deleted and then reinstalled 1Password for iPad?
- Why did 1Password for iPad offer to display her master password to me when it encountered a problem syncing with my keychain?
Your responses are focusing on the first question. That question may be interesting from the engineering side of things, but it’s not the issue. The issue isn’t why the password was still on her iPad. The issue is that 1Password for iPad gratuitously disclosed it. Why in heaven’s name would the app ever display a user’s most sensitive password—the last password you’ll ever need [sic]?
I seem to have inadvertently discovered a way to steal a master password. I imagine that it might be difficult to reproduce the anomaly now that Dropbox has shut down the old API, but I take no comfort from that.
If I stumbled onto this, then others might have stumbled onto it as well. And if that is the case, then there is no telling how many of your users’ master passwords have been compromised. Should your user base not be alerted?
0 -
Do you recall what the original title was. I'll try to correct it.
You are correct that I ducked out of the second question:
The issue is that 1Password for iPad gratuitously disclosed it. Why in heaven’s name would the app ever display a user’s most sensitive password
With 1Password 3 there were three passwords that people had to deal with. (Four if you count the low-security PIN).
- Local Master Password
- Master Password for data stored on Dropbox
- Dropbox login
A huge number of support queries and synchronization difficulties were the consequence of people using the wrong password in the wrong place. Enabling people to see which password was saved where made a big difference in getting sync working for a lot of people.
In retrospect, we should have tried to do something a bit more clever, such as presenting only the the first few and last few characters of the stored passwords.
At any rate, this is moot now that we don't have to store those. We only have to store sync service credentials.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
At any rate, this is moot now that we don't have to store those. We only have to store sync service credentials.
The fact that 1Password 4 for iOS does not share the vulnerability is irrelevant. 1Password HD may still be installed on many iPads, and if it is absent from an iPad it can still be installed or reinstalled by anyone who ever purchased 1Password HD or 1Password Pro.
It may be moot prospectively if the demise of the old Dropbox API eliminates the possibility of triggering disclosure of the stored master password. Even if this is the case, the fact that an exploit did exist in 1Password HD remains. Everyone user of 1Password HD (or 1Password Pro on the iPad) was, in principle, vulnerable to this "zero-day" attack. Would changing one’s master password be advisable, or would that amount to merely locking the barn door after the horses have escaped? What should your user base know? (I realize that Agilebits does not know the identity of its App Store customers, but there are ways to get the word out.)
0
