Filling with your approval: On 1Password’s App Extension and iOS 8 security

iOS 8 has an incredible feature coming called App Extensions, and we’re thrilled to say we have a 1Password extension ready for developers to use right in their apps! In apps that gain support for our extension, you will no longer have to copy and paste passwords from 1Password. Yes, it really is a game changer.

Naturally, this new-fangled way for apps to interact in iOS 8 is leading people to ask how we do this in a secure manner:

• Are we really letting third-party apps poke around inside of your 1Password data?

• Answer: No, that is not how extensions work.

• Can these third party apps ask 1Password for your PayPal password?

• Answer: Well, they can ask, but you decide if they should get what they ask for.

• Can they trick you into entering your 1Password Master Password into something that isn’t 1Password?

• Answer: The very same mechanisms that prevent that today apply to application extensions.

TL;DR

I will elaborate on all of this below. But to summarize, all of my points and these safeguards in both iOS extensions and 1Password are built on an important design principle: Nothing happens without your explicit action.

Words, words, words

To explain all of this, we are going to need some terminology. I will try to follow the same terminology that Apple uses in their documentation.

User

The User is you. The human being who is using all of this stuff.

Host App

The Host App is the application from which the user calls the extension. In our example video, the Host App is ACME application (for ordering your catapults, rockets and other tools needed to catch desert fowl).

Container

In iOS, each app runs inside of its own “container.” This is forced by the operating system, and it prevents one app from interfering with the operation or data of another. This is central to iOS security.

The Container App

The container app is the app with which the extension is built. In our example, the container app is 1Password. Like every app, the container app operates within its container.

The Extension

The extension is a special program (it is not a full app in its own right) that takes requests from the host app. It may have access to the container app’s container. In this way, it “extends” the container app. This is not to be confused with the 1Password browser extension on Mac and PC. In this article, I will be using the word “extension” to refer to the app extensions in iOS.

Who talks to whom and when?

The host app makes a request to an extension. For example, the ACME app might make a request to the 1Password Extension to look up a username and password that a user might have in 1Password for acme.com.

The extension is allowed to do stuff within the container app’s container. So in our case, our extension can do stuff within the 1Password container just as the 1Password app itself can. After the extension does its stuff, it gives a response back to the host app. As another example, the 1Password extension might pass back a username and password to the ACME app.

What I have just described sounds dangerous. Fortunately, it isn’t, thanks to a couple of things that are built into the foundation of this system.

User control (part 1)

The host app doesn’t get to decide when it makes a request to an extension. The only time that the host app is able to talk to an extension is when the user—that’s you—asks it to. The host app cannot silently poke at the extension to get data. It can only make a request to the extension when you take explicit action. You need to tap on the 1Password extension button each and every time you want the ACME app to make a request to the 1Password extension.

Doctrine of Containment

Only the makers of the container app can make an extension for it. The 1Password extension is built along with 1Password itself and is signed with the same cryptographic keys. Both the container app and the extension have their own containers, but we can also specify a shared container. This way the container app can decide just what data from its own container is made available to the extension.

The 1Password app makes most of its data available to the shared container. The extension wouldn’t be able to do much otherwise. Don’t forget, of course, that your 1Password data is encrypted. It is encrypted with a key that is itself encrypted with a key that is derived from your Master Password. So even if it were to somehow escape from its iOS container, it cannot be unlocked without your Master Password.

All of this means that we and you have tight control over the requests that come in from the host apps. You control exactly when a host app can send a request to the extension. Our extension limits which kinds of requests it takes. The extension, of course, cannot decrypt any of your data unless it is unlocked.

Selecting what gets sent back to the host app

Glendower: I can call spirits from the vasty deep. Hotspur: Why, so can I, or so can any man; But will they come when you do call for them? —Shakespeare (Henry the 4th, Part 1)

It is up to the host app to create a request to the 1Password extension. In our example, the ACME app might make a request for the username and password for the ACME Login. This is what the extension is built for.

But now, imagine that the good folk at ACME were not so good folk after all. Say that, instead of asking for your ACME login information from 1Password, it asked for your PayPal Login. The 1Password app extension has no way of telling if that is an appropriate request or not. Note that this is very much unlike the situation with the 1Password browser extensions that you may have in your web browsers on Mac and PC. Our own browser extensions are what formulate requests; but when it comes to these app extensions, it is the host app that makes the request.

This is where you come in. The 1Password extension will present you with a list of Logins that match the request made by the host app. You have to select the 1Password item (even if there is only one in the list) that gets sent back to the host app. If nothing looks right, then don’t pick any of them. You have to check that the item you send back is information that you wish to give to the host app.

One large advantage of all of this is that, because the operating system is managing this through interprocess communication, the item you select is passed back to the host app in a far more secure manner than the copy-and-paste mechanism this replaces.

Which extension?

So, when you tap the action button and the 1Password Extension, how do you know it’s the 1Password Extension that launches? How can you be confident that you are truly typing your Master Password into the 1Password Extension?

This is a thorny issue, but it is not a new one. The iOS solutions that have worked for similar scenarios should continue to work with App Extensions. Just as you must explicitly decide which apps you install on your device, you also explicitly decide which extensions you enable. Just as you wouldn’t install an app that masquerades as 1Password, you wouldn’t enable an extension that masquerades as 1Password, even if such apps or extensions were to sneak through Apple’s review process.

If you would like to know more about how iOS determines which extension to launch when you tap an extension button, please read on. But if you wish to stop here, then just keep in mind that you are in control of what extensions get installed and enabled on your device.

In the scheme of extension selection

When you look at a URL like http://agilebits.com or https://discussions.agilebits.com or mailto:support@agilebits.com the part before the first colon (“:”) is called the “scheme” part of the URL. When you select your default browser or email client on your Mac or PC, you tell your computer which program should “handle” each scheme. Your particular web browser (Safari, Firefox, Internet Explorer, etc.) gets registered as the “handler” for the http: and https: (and perhaps ftp) schemes.

Schemes like http:, https:, ftp: are all standardized. But it is possible to register other schemes as well, such as onepassword: with 1Password as its handler.

iOS application extensions use this same scheme. When you install and enable an extension, you say that the particular extension will be the handler for some particular scheme. If (once you get the chance) you install our 1Password extension on iOS, it will be the handler for the schemes org.appextension.find-login-action:, org.appextension.save-login-action:, and org.appextension.fill-webview-action:.

When you tap the extension button within the ACME app to get a particular Login, the ACME app will send a request that might look like org.appextension.find-login-action://search?url=https://www.acme.com. The operating system—in this case, iOS—will look to see if there are any extensions which have been enabled by the user and which claim to handle org.appextension.find-login-action:. The 1Password app extension is such an extension.

User control (part 2)

The 1Password app extension may not be the only extension available which handles org.appextension.find-login-action:. Other container apps may introduce an extension which handles that type of request. If you install one of these apps, then its extension will launch.

If you enable the 1Password Extension for handling these requests, then it is perfectly safe to enter your 1Password Master Password into the extension that opens. If, however, you install and enable some other developer’s extension for handling those sorts of requests, you should not enter your 1Password Master Password into those extensions.

You remain in control of what extensions you install and enable. Just as you remain in control of what apps you install. Just as you shouldn’t enter your 1Password Master Password into some app that isn’t 1Password, you shouldn’t enter your 1Password Master Password into some App Extension that isn’t 1Password.

We’re using a brand-neutral URL scheme on purpose

You might have noticed that the identifier domain we are using for the handler is org.appextension (don’t worry about why these are backwards from ordinary domain names such as appextension.org. Despite appearances, this reversal of order is not to give nightmares to those who managed email systems in the United Kingdom during the 1980s). We could have used an identifier like com.agilebits.extension.find-login-action or com.1password.extension.find-login-action. That is, we could have tied the scheme to our brand. We didn’t. We created an identifier that is brand and product neutral.

This enables developers to simply call the brand neutral org.appextension.* schemes. When you, the user, call on an extension to perform these tasks, you will get your favorite password manager extension; the one you enabled on your device.

Our brand-neutral scheme should make things easier both for users and for app developers. Thus, part of our reason for using a brand neutral scheme is to encourage as many app developers as possible to use this scheme. We aren’t forcing app developers to choose between 1Password and some competitor. Instead, we are delegating the choice of which password manager to use to where that choice belongs: you.

The more people using password managers, the better

Promoting wide adoption of this scheme isn’t the only reason for making it brand neutral. It may not be a very businesslike thing to say, but we would rather people use any (decent) password manager than not use one at all. Of course, we feel that 1Password is the best choice for just about everybody, but we’d still rather see you use a competitor’s product than to not be using a password manager at all.

The reasons for this should be obvious. There are the self-interested ones, such as the fact that on a very interconnected network one person’s security problems can easily become another’s. With apologies to John Donne: Ask not for whom the reused password tolls. It tolls for thee, for thou art connected to all mankind.

Another selfish reason, I suppose, is that there are an enormous number of people who don’t use a password manager at all. “Growing the industry” will help AgileBits, even if some of that growth goes to competitors. Quite simply, it is good for our business if people have already answered “should I use a password manager” and have moved to the question of “which password manager should I use.”

Plus, when we learn about how most people manage their passwords (typically massive password reuse), it hurts. When we hear about people not registering for something they might find useful because they don’t want to deal with yet another login to manage, we are saddened by the lost opportunity. When we see accounts broken into when it could have been avoided, we cringe.

Quite simply, we are in this business because we think it does a lot of good. We look forward to seeing apps add support for password managers, more people using strong unique passwords, and a more secure world.

Jeffrey Goldberg

Principal Security Architect