Archive for November 15, 2016

Tuesday, November 15, 2016

About Touch ID Security in 1Password for Mac


When you enable Touch ID, 1Password stores in the macOS Keychain an obfuscated version of a secret that can be used to decrypt your 1Password data. The secret is used to unlock 1Password when your fingerprint is recognized. It is stored using these attributes:

  • 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.
  • kSecAttrAccessibleWhenUnlocked — This means that nothing can access the secret when your Mac is locked.
  • keychainGroupIdentifier = "" — This means that only 1Password can access the secret unless you enter the password you use to log in to your Mac.

1Password removes the secret from the macOS Keychain when the amount of time in Preferences > Security > Require Master Password has elapsed.

This is new in 1Password 6.5. It sounds pretty much like the situation on iOS, but due to the differences between the operating systems it does not seem as useful to me. On iOS, Touch ID is a killer feature. You trade a bit of security for a lot of convenience. The secret is stored in the device keychain, which is hard to access because iOS is so locked down, and in return you can avoid having to type your long master password using a tiny glass keyboard. On the Mac, it’s easier to access the keychain, and it’s probably backed up to other hard drives or cloud services. As to convenience: you’re typing on a full-size keyboard, and 1Password already had a way to remember your password in RAM. (Unlike on iOS, the 1Password helper app can keep running in the background for as long as you want.) So how much is this really gaining you? None of this is to say that Touch ID is a bad feature—but, rather, that the context in which it appears can make a big difference.

Previously: 1Password 5: Touch ID and Safari/App Extensions.

Testing Actions Over Time

Matt Gallagher:

I’ll show a way to test events scheduled over time, threads and other execution contexts with a DebugContextCoordinator that functions as a basic task scheduler but operates over a simulated version of time so that testing of invocation times and task interaction can be precise and free from changes due to host activity.


Now that libdispatch is replaced by the more flexible Exec, we can use the flexibility to schedule events with something other than libdispatch.


The advantage with using a DebugContext and DebugContextCoordinator to handle timing is that you’re no longer dependent on the actual timing information from the host machine, leading to greater precision and greater reliablility in testing.

Incremental Swift

Amy Dyer:

We said, “Instead of living with just Objective-C or Swift, let’s be a two-language code base. Let’s commit to that.” And this was actually a smart decision, I think, because realistically if we were porting our app one piece at a time, it would take us years to get completely to Swift anyways.


Xcode forgets what language you are looking at and gives you the header for the wrong one. More importantly, developers need to know two languages, which is also a disadvantage in terms of education. And finally we have to deal with all of those messy interoperability features i.e. bridging headers and auto-generated Objective-C.


The solution we landed on was to annotate files while you import them. Your Swift bridging header is the firewall between your Swift code and your Objective-C, as long as you annotate things there, you will be safe.


All we decided is that if you are going to use, for example, a generic or struct, make sure it is flagged as private. You can write your very Swifty code, but it will be interfaced for it. You are forced to write something that you can still use from Objective-C.