What is the unique code combined with the master secret to support Touch ID unlocking?
First, thank you for the technical details presented in the article "About Touch ID security in 1Password for Mac" (https://support.1password.com/touch-id-security-mac/). I have a couple more questions.
One passage in the explanation says "kSecAttrSynchronizable — This means that the secret is synced with iCloud Keychain. However, Apple can’t access it. Additionally, it’s combined with a unique code that’s only stored locally by 1Password, so it’s not usable on any other device." What is this unique code? How long is it? How is it generated? How is it combined with the secret? Where is it stored? In particular, is it somehow also synced with iCloud/iCloud Keychain?
I wish to use the Touch ID unlocking feature but I want to minimize the chances of the master key spreading to all of the Apple devices I have, of which there are many and difficult to tightly control. I don't install or use 1Password on all of them. In other words, I don't want the security of my 1Password vault to be tied to the security of the iCloud Keychain on my least secure Apple device synced with my iCloud account.
1Password Version: 6.6.2
Extension Version: Not Provided
OS Version: 10.12.3
Sync Type: Not Provided
Referrer: forum-search:Touch ID security
Comments
-
@planetbeing: Thanks for reaching out. I’m sorry for the confusion! As you can imagine, we don't want 1Password's security to depend on iCloud (or anything else) either, so we've designed it with that in mind. I think you already answered (part of) your own question: The unique code is stored only locally by 1Password, meaning it never leaves your Mac. It's created using the system’s secure random number generator (the same as is used for 1Password and macOS in general). And while the Master Password is stored in the Keychain, it's not accessible to Apple, does not sync to other devices, and is obfuscated and combined with a unique code so that it wouldn't be recognizable to anyone who was able to access it (presumably only you, unless you give others admin privileges on your Mac). I hope this helps. Be sure to let me know if you have any other questions! :)
0 -
Thanks for the response. I think I was hoping for detail on a little more technical level, but I looked into it a bit on my own. The unique code (scramble code) is a 512-bit key created from SecRandomCopyBytes, which I agree is secure. It's stored in ~/Library/Containers/2BUA8C4S2C.com.agilebits.onepassword-osx-helper/Data/Library/Preferences/2BUA8C4S2C.com.agilebits.onepassword-osx-helper.plist which doesn't seem to be sync'ed. The file is readable to anyone sitting at my computer when I'm logged in and my screen is unlocked, so that's a potential risk, since that's slightly more likely to happen than if that is true AND my 1Password vault is unlocked. Thanks to FileVault, the file is not readable when the computer is off to anyone who doesn't know my computer's password. If anyone does, using Touch ID to authenticate is not going to be secure in any case. For people who haven't enabled FileVault (which luckily is on by default for computers with Touch ID), the file can be read by anyone with physical access to the computer.
The encrypted Master Password is stored in the keychain and it actually is synced to other devices (as the article I linked to earlier states). I tested it by having the Keychain Access on one of my computers while enabling Touch ID on another computer. Two passwords named "lock-service" were created when Touch ID was enabled, one of them contained the encrypted Master Password. (Obviously not useful unless one can obtain the scramble code off the computer Touch ID is being used on).
If the adversary somehow got a hold of another Apple device sync'ed with the same iCloud Keychain but had a weaker computer password (or an outdated iOS device with a weak passcode), they could possibly get a hold of the encrypted master password and decrypt it with the scramble code they might skim off my computer if I leave it unattended with the screen unlocked.
I don't think it's a huge risk unless you have really determined adversaries, but it seems like an unnecessary one to take. I hope that future implementations of this system will not store the encrypted master password in something that is cloud sync'ed, but only locally on the computer. It just seems like an unnecessary risk.
0 -
Great sleuthing @planetbeing!
I have no technical corrections of your assessment. The nut of the problem here is that we need a place to store a secret needed to unlock the app. The Touch ID APIs don't give us anything but a simple boolean indicating success/failure. On iOS we store the unlock secret within the iOS keychain, set not to sync. I really wish that this was possible on the Mac. In some ways, it is. We could store the unlock secret in the Mac Login Keychain. Unfortunately there are some pretty big usability problems with doing so. The first is that upon accessing the keychain, the user gets asked for permission. If the user rejects access then the feature doesn't work. Upon updates of the app, the system wants to ask permission again. We issue a lot of updates (especially betas) and having the system nag the user to allow us access to the keychain is really a non-starter for us. The second issue is that the user is able to lock the Login keychain and set different lock rules for it. This means that a critical feature of 1Password would be depended on lock state of another component of the system that is outside of our control. Every time we've added a feature that was depended on the system Login keychain, we've regretted it and ended up walking away from it.
On the Mac, the only way to get access to a keychain that's iOS-like is by using the kSecAttrSynchronizable flag, which then has the unfortunate side effect of being synced to other devices. This gave us a place to store a secret, but the fact that it's synced made us feel less than 100% about it. Assuming all of your systems have strong passwords, it's probably fine... but we wanted to do better. This is where that other key came in. We wanted to make having access to the sync'ed secret useless unless you were on that system. By encrypting it with a random key that we store in an unsynced location on disk we achieve that goal.
You can disable iCloud Keychain, which still allows the feature to work as the keychain in question then gets renamed to Local Items but functions the same (sans sync).
We've filed enhancement requests with Apple to see if we can get the behavior of iOS on the Mac without the synchronizable flag.
I hope this helps.
Rick
0 -
It does! Thanks! I didn't know that about the Login keychain and software updates, and your technical decisions make sense in light of that. I hope Apple makes those changes to macOS.
0 -
Me too. Considering our constraints I'm happy with our design. But I'd be happier without that flag. :)
Rick
0
