How 1Password syncs changes to your Master Password

At the risk of being blackballed by the Alliance of Magicians, we want to reveal the secret to Master Password syncing. It’s all just an illusion — a clever one — but since we don’t actually store your Master Password, we don’t sync it for you either. You do, but we’ve made it look like we do.

There are a lot of seemingly mysterious things that go on when a Master Password changes, so it is quite reasonable to have questions about security in this area. A cornerstone of Master Password security, though, is that 1Password never stores your Master Password in any form. (A not very relevant exception is for use with Touch ID.)

Suppose you change your Master Password on one of your computers. The next time you unlock 1Password on some other device, you can unlock it with your new Master Password. How can 1Password on the second machine accept the new Master Password if we are careful to never store it? This has led a lot of astute users to mistakenly imagine that their data isn’t really protected by their Master Password. But, let me assure you that it is, and all the tricks up our sleeves make things both more secure and more convenient for you.

The Basics

At its most basic, a 1Password vault (be it a local vault in 1Password for Mac/iOS, or a sync vault in the form of an Agile Keychain or an iCloud vault) contains a couple things:

• A universally unique identifier (UUID)

• An AES key used to encrypt and decrypt items

Every vault has a different UUID, and a different AES key. These are both randomly generated when the vault is created. This means that your local Mac vault does not share a UUID with the Agile Keychain it’s syncing with, and any other Mac or iOS device that’s also syncing with that Agile Keychain will have its own UUID/AES key combination. In the simplest scenario of a Mac syncing with an iOS device via Agile Keychain, that’s 3 vaults, 3 AES keys.

Obviously, it’s a bad idea to store the keys unencrypted. It would be like leaving your house key on a hook next to the door, outside. We need a key to encrypt your AES key with. For this, we use the Master Password you provided when you created the vault to derive another key. The key that is derived from your Master Password is then used to encrypt your vault’s AES key. We never store the derived key anywhere.

Let’s look at a very basic example. You have an unsynced vault on your desktop. To unlock 1Password, you provide us with a Master Password (which may or may not be correct). We use this Master Password and go through the same key derivation process that we used originally. If it’s the same Master Password, the result will be the same key.

A key will be derived even if an incorrect Master Password has been entered. Determining whether it’s the right key is a matter of attempting to decrypt the AES key. A successful decryption indicates that the correct Master Password for this vault has been entered, thus the vault will unlock. If the decryption fails, it’s the incorrect Master Password.

Master Password Changes

Now that we know how your vault is unlocked with your Master Password, let’s discuss what happens when you change your Master Password (leaving sync out of the equation for now). When you change your Master Password locally, the vault’s UUID and AES key do not change at all. What changes is the key that is used to encrypt your AES key (the one that’s derived from your Master Password). Effectively all that changes is the encrypted form of your vault’s AES key. It’s encrypted with the new key, derived from the new Master Password.

This means that trying to use your old Master Password will generate the old derived key, which will not be able to decrypt your AES key that’s now encrypted with the newderived key. Simple enough.

Master Passwords and Syncing

It is important to reiterate that your Master Password is never stored anywhere. This is the case for your local vault as well as the Agile Keychain you’re syncing to, so we’re essentially responsible for syncing something we don’t have. This is important as it allows 1Password to continue syncing even after you’ve changed a Master Password on one device.

During initial sync setup, we ask you for the Master Password of the sync vault (typically an Agile Keychain). We use this password to unlock the sync vault, but once it’s unlocked we throw away the password you gave us. Instead of the password, we store the sync vault’s UUID and its AES key, and we encrypt those with our local AES key. We know that a vault’s UUID and AES key will never change for the lifetime of the vault. This means that as long as we know that we have the same vault (the UUIDs match), we’ll be able to use the AES key we have to decrypt its data (even if the encrypted form of that AES key was changed to be encrypted with a new key derived from a new Master Password).

This allows us to sync multiple devices, each having their own Master Password. They don’t actually need to have the same password, and as one device changes its Master Password, even though the sync vault’s Master Password will also get updated, the other devices don’t necessarily need to care.

Please note, while this suggests that you could potentially use a different Master Password on each of your devices, we do not recommend that you attempt it. The mechanism described above is merely necessary to ensure that the Master Password changes are able to be synced.

Syncing Master Password Changes

When you change the Master Password of a vault on one device, the same process that happens locally for a Master Password change happens to the sync vault. We re-encrypt its AES key with the new derived key. This makes the sync vault’s Master Password the same as the new local Master Password. To read data within this vault you need either the new Master Password or a copy of its AES key.

Now that you’ve changed the Master Password on one device, and it has changed the Master Password of the sync vault, what you want is for all other devices associated with this sync vault to also have the new Master Password. Unfortunately, we’ve done all of the pushing we can. Despite the fact that we can detect that the Master Password in the sync vault has changed, we don’t know what it has been changed to because we don’t store your Master Password anywhere. We have no way of knowing what key to use when re-encrypting the AES keys on your other devices. So, from here on, we need your help!

The other devices still have the old Master Password. That old Master Password will still work to unlock your vault on these other devices because the AES key is still stored, encrypted with the derived key from your old Master Password. These vaults can continue to sync with other devices because they happen to have a copy of the sync vault’s AES key. They don’t need to care about the sync vault’s Master Password.

Updating the Master Password

At the start of this post, I said that the process of unlocking a vault is a matter of deriving a key based on the provided password, and attempting to decrypt the vault’s AES key with it. If the decryption of the vault’s AES key is successful, we’ve unlocked the vault. If the decryption is unsuccessful, then we’ve failed to unlock the vault. It turns out that this isn’t quite true, at least not in the case of synced vaults.

If the decryption of the vault’s AES key is successful, we’ve unlocked the vault. That part is true. But if the decryption is unsuccessful, all it means is that we’ve failed to unlock the local vault with the provided key. When a failure is detected, we look to see if we’re syncing with any vaults. Then we try the Master Password against the sync vault as well. If the Master Password that you have entered is the new Master Password of the sync vault, unlocking the sync vault will be successful. This tells us that the password you entered is the correct Master Password for the sync vault, and from that we can infer that this is the new Master Password that you would like to use on this local device.

This is all well and good, but we’ve really only managed to unlock the sync vault, not your own local vault. Remember how we stored the sync vault’s AES key, encrypted with your local AES key so that we could keep syncing even after the sync vault’s Master Password changed? It turns out doing the reverse here is possible. When we set up sync, not only did we store the sync vault’s AES key encrypted with the local AES key, but we also stored the local AES key encrypted with the sync vault’s AES key. This means that as long as we can unlock one of the two vaults, we can unlock both. We can use the unlocked sync vault to decrypt our own local AES key to unlock your own vault.

So we’ve used the new Master Password to unlock the sync vault, then used the sync vault to unlock your local vault. All that’s needed to do now is re-encrypt your local AES key with the new Master Password. And voilà, the next time you unlock 1Password with that new Master Password the decryption will succeed.

Recap

That might sound like a lot of information. Let’s go over that again, in simple, flow-chart form:

• Device1 and Device2 sync via Agile Keychain, all share MasterPassword1

• Device1 updates to MasterPassword2 by re-encrypting Device1’s AES key with key derived from MasterPassword2

• Device1 updates Agile Keychain by re-encrypting Agile Keychain’s AES key with key derived from MasterPassword2

• Agile Keychain files sync to all devices

• Device2 attempts unlock with MasterPassword2

• Device2 rejects unlock with MasterPassword2

• Device2 attempts to unlock Agile Keychain with MasterPassword2

• Device2 successfully unlocks Agile Keychain with MasterPassword2

• Device2 uses Agile Keychain’s AES key to decrypt a copy of Device2’s AES key that was encrypted using Agile Keychain’s AES key, earlier when sync was originally setup.

• Device2 uses decrypted Device2 AES key to unlock its local vault

• Device2 re-encrypts its AES key with key derived from MasterPassword2

• Device2 unlocks

• Device2 locks

• Device2 attempts unlock with MasterPassword2

• Device2 unlocks

So, there you have it. The secret of our illusion: the Master Password update has propagated to another device without the password itself being stored anywhere.

Rick Fillion

VP of Engineering: 1Password.com