At the risk of being blackballed by the Alliance of Magicians (from even the smallest venues), 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 new derived 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:

Does this mean it is impossible to revoke access to a vault once someone has the password to it?

For example, imagine that Alice trusts Bob and shares a vault with him, locked with a mutually known password. Then for some reason Alice decides to no longer trust Bob, so she changes her master password and then goes to each website and changes all of the passwords in the vault. Can Bob can use his old password to get the AES key from the old vault, and use it to unlock Alice’s vault with all of the changed passwords?

I’ve noticed similar behavior as well. If Bob and Alice have a mutually shared vault (perhaps because they’re married), once they are divorced, Alice has no way to revoke access to that shared vault (other than stop syncing and change every password).

Another way of characterizing is this – a shared vault is only as strong as the weakest master password among the pool of shared users.

I am a huge 1Password fan and would love to hear their thoughts on a) the accuracy of my statements and b) best practices to avoid its pitfalls.

That is correct. Bob can still reuse the AES key as it is the same even after Alice changes her password. If Alice has not stopped sharing the data vault with Bob, Bob will continue to get her new information until Alice kills the sharing of her vault.

The only thing you can do is prevent future changes. Whatever you’ve already shared, it’s shared fully with the person you’re sharing with. Note even if you could revoke the access, that doesn’t stop the person from exporting the data from his 1Password database before your revocation.

That is an excellent question, Richard. You can revoke access to a vault, and that does prevent someone from seeing future changes to it. You can read more about this in our support article here: https://support.1password.com/revoke-shared-vault-access/ So, in your example, Bob still has access to the old data (and can unlock it), but because Alice has stopped sharing the vault with him, he has no way to access the passwords.

Just as in everyday life, “if you have whispered a secret to someone and later decide that you don’t want them to know that secret, there is no way to ‘untell’ that secret. We can’t predict what others will do with complete certainty, but if you think someone may use your secret against you in the future, it is wise not to share it with them now.”

Mike, Khad – it seems you are saying that as long as Bob has physical access to the vault file, he can see all of Alice’s changes in the vault, no matter how many times she changes the password.

This is an important detail to point out, and you should write it in large print on the “change password” dialog (if it isn’t there already – I haven’t tried it). It seems to me that a major reason for changing a password is if you think the old password and/or file has been compromised – but from what you are saying, changing the master password in this situation is pointless because anyone who could get into the old, compromised vault can unlock the new one too.

Ideally, the “change password” dialog should also provide an easy option for doing what Steven Fisher suggested, which is exporting all the passwords to a new vault with a new AES key. This would be the only way to reliably recover from an attack where your whole system is compromised.

You’re mostly right. In that once you’ve given someone access to a sync vault, there’s no perfect way to revoke that access.

If Bob and Alice sync via BobAlice.agilekeychain, and Alice decides she no longer wants Bob to have access to anything, then Alice should disconnect from BobAlice.agilekeychain, and setup AliceOnly.agilekeychain. AliceOnly.agilekeychain will get a new AES key which Bob has no way of getting.

You’re right that if your whole system is compromised, the only good solution is to do a full export, create a new vault, and import. It would be nice if helped automate that process.

I’m curious about these 3 vaults, when syncing with Dropbox. The vault stored in my Dropbox (e.g., Dropbox/1Password/1Password.agilekeychain), is this my Mac vault or the sync vault? I thought it only was one vault that was synced through Dropbox.

Does this indicate that when syncing from Windows -> iOS (via wifi, in this case) that the master password is not sync’d as described above? Very curious about this because the behavior I observe is that the passwords do not sync in this scenario.

You’re right that syncing 1Password for Windows via Wi-Fi to 1Password for iOS will not sync the Master Password. Mac to iOS via Wi-Fi does support password sync though.

The reason for the differences there is a little complicated. Let’s see if I can boil it down…

Sync requires a sync vault, which is typically an agilekeychain file. When Wi-Fi syncing from a Mac, the sync vault is actually the same as the Mac’s local vault. Which is similar to how a PC accesses the agilekeychain directly when syncing with iOS. Every time the Mac and iOS device sync, as part of the authentication the Mac sends the iOS device the encrypted vault keys for it to try to decrypt. Since we always have the latest (or very close to latest) encrypted keys from the Mac we can use that to do Master Password syncing.

On the PC side, things work a little differently. 1Password for Windows doesn’t use its own vault as the sync vault. Instead every time you initiate sync a new vault with new keys is created. This plus some other technical issue makes it impossible for us to sync the Master Password in this specific case.

We’re working towards standardizing how this kind of stuff works so that expectations can be the same regardless of which platform is used.

As a new user of 1pw, I do find it confusing sometimes when there are differences in behavior of the app depending on which platform I’m running on. I feel like cases like this could be spelling out more clearly in the 1pw guids.

I’m not totally certain I understand specifically what you’re asking, but if you’re wondering why we don’t use an RSA key instead of an AES key to encrypt/decrypt your data, the answer is essentially that, like most asymmetric encryption, RSA is much more computationally “expensive” than symmetric ciphers like AES. It uses math with extremely large numbers, and the larger the block size (and more times these encryption/decryption operations need to be performed), the more taxing it is. This makes RSA much slower than AES.

If I’ve misunderstood what you were asking, would you mind elaborating on it, please?

This explains a lot of my questions when 5.3 was installed. I was curious why my Device1 had suddenly lost its own master password and would only accept the master password I only used on Device2 and Device3.

I am not a 1password user, but I am a probable future user. In this article author said that the Master password is not stored anywhere. Does this mean that it isn’t stored even locally on my machine? Then how does the app verify whether my inputed password is right or wrong?

I will really appreciate any answers as they will clearly help me in reaching finality regarding password security, thanks!

Thank you for asking such an awesome question and giving me a chance to talk about how things work underneath the covers ?

Your Master Password is indeed not stored anywhere locally on your machine. Instead, we take your Master Password and use it to derive a key that is used to perform the encryption of your data. This encrypted data is what gets stored locally and synced to your other devices. When you want to unlock 1Password at a later date, you enter your Master Password and we once again derive a key from what you entered and attempt to decrypt your data. If the decryption is successful, then we know that you entered the correct password and proceed to unlock 1Password.

There is one exception to this rule and that is if you configure 1Password to unlock with your fingerprint. In this case we ask the operating system to store your Master Password for us (for example, on iPhone it is stored in the secure enclave provided by iOS) so we can have it handy after you successfully unlock using your fingerprint.

I hope that helps explain things. Please let me know if you’d like to dig deeper and we’d be happy to! ⛏?