Master password confusion: MUK, SRP, and the Windows 6.x families client

analogist

Hi! I am a little confused about some of the prompts in the Windows 6 families client interface, and would like some help in clarifying it if possible.

In the Windows 6.1 client, the Change Master Password prompt states: "This will update.... on this device and will not update any 1Password accounts or remote vaults". This seems strange to me since, if I understand the design of 1Password for Families/Teams, the Master Password should be used to both derive both the "MUK" and the SRP authentication to the 1PW server, and so if I ever felt the need to change it, the change should also lock an attacker out of server access due to the changed SRP (by server policy, at least).

I searched for similar comments and found this thread from just a couple days ago, where Jacob said that "Updating the Master Password in 1Password 6 for Windows does only update it on that device."

I am confused because this isn't how I understand how the 1PW product to work. I'm confused whether as to:

• that answer was just specific to that particular user's previous usage of 1PW4 on Windows and does not apply to 1PW6?
• Or is this the case that the SRP identifier is never changed again with local Master Password changes and that's the case with all 1PW for families clients, and the Families product actually differs from the Teams product as described in the white paper?
• Or is this a current problem with just the Windows edition that will be corrected in the future? If it's just a current problem with the Windows edition, what is currently going on with the SRP on Windows clients? Is it just permanently cached locally and unchanging? Wouldn't that mean that if I change the Master Password using a Mac client (or the js client) it would then lock me out of Windows access?

Thank you for your help in clarifying this, as the security design is important to my (and I'm sure many users') peace of mind.

---

1Password Version: 6.1.286
Extension Version: Not Provided
OS Version: Windows 10
Sync Type: Families

AGAlumB

@analogist: Thanks for reaching out. I’m sorry for the confusion there! The short version:

It's definitely confusing, and it's something we're working to improve to get to "it just works". the new 1Password 6 Windows desktop app. 1Password Teams and Families (and individual accounts) are the same on the technical level. The new Windows app simply does not yet support sending Master Password changes to the server.

Interestingly, it's the same in both the new 1Password 6 Windows desktop app (because, well, it's really new and we haven't implemented this yet) _and in 1Password for Mac (because it was originally developed when local vaults were the only game in town).

The problem, from the user perspective, seems the same (having to update the Master Password on multiple devices), but it exists for different reasons in each case. For example, while 1Password for Mac can send Master Password changes to the server for a 1Password Account, if you're like me and have local vaults, the Primary vault's Master Password will be the one used to unlock the app; and changing the Master Password for a local vault (understandably) has no impact on the one(s) used for any 1Password Account(s) used in the app in addition to the Primary local vault.

However, to add further confusion to confusion, since 1Password doesn't store your Master Password, it doesn't actually sync your Master Password at all, under any circumstances. This is done cryptographically with local vault key, which can then sync to other devices, and then (after unlocking with the "old" Master Password to access changes to the data) only the correct "new" Master Password will be able to decrypt it going forward. This is, for example, how you can use the same Master Password in 1Password for Windows version 4 and other devices after changing the Master Password. Different to 1Password for Mac version 6, 1Password for Windows version 4 can only read local vaults. So when it comes to 1Password Accounts, version 4 of the Windows app doesn't come into play.

Sorry for rambling, but I wanted to put everything into context. Getting back to 1Password for Windows version 6 and 1Password Accounts, the app also has read-only support for local vaults, so whichever you add first — local or account — will be the app's Master Password. This can be changed on the device, but in both cases, the change will not propagate anywhere else: local vaults are read-only, and also the app does not yet support sending the change to the 1Password.com server either. Ultimately what we want is for this to all be transparent to the user, but right now things are a bit complicated due to the intersection of legacy support and a new codebase.

I hope this helps shed some light on things — both where we've been and where we're going. Be sure to let me know if you have any other questions! :)

analogist

(I wrote this months ago and forgot to post it)

Thank you for the prompt and concise answer to this :)
After verifying with the Whitepaper, and the thread at https://discussions.agilebits.com/discussion/comment/329659 with clarification from @jpgoldberg I think I understand what's going on. My question was twofold, and I think I now understand that:

Re the SRP:
I originally thought (which was what led to the original question) that each sync with the server re-derived the SRP-x every single time the MUK was entered, but I see that that would then require 200k rounds of PBKDF2 every single unlock, which at the time of design was probably not acceptable. I see now that the SRP-x is just created once, wrapped with the MUK (or is it wrapped with the encSymmetricKey?), and then saved, which means unlocking is only a single 100k derivation round.

Re the MUK:
Key wrapping is employed twice on the RSA private key: the RSA (encPrivateKey) is wrapped in encSymmetricKey, which is wrapped in the MUK, which in turn is "never saved". The future plan is to sync encSymmetricKey and thereby indirectly "sync" the MUK (I think?), but currently at this stage this is not done and each device is allowed to have its own encSymmetricKey. This is presumably so that the same encSymmetricKey can then be used to both (1) wrap the Teams/Families encPrivateKey, as well as (2) unlock local (OPvault) vault ("master", I think you call it) keys, simplifying the user experience in unlocking.

I think what caused me the most confusion was the White Paper pages 24-25.

The summary steps in the white paper do not show the double wrapping by encSymmetricKey (it just says "Encrypt private part [of the RSA key] with MUK"). While the later examples show encSymmetricKey, there wasn't clarification of what it did. The other discussion thread (and @brenty 's clarification) made me realize you were double wrapping the encPrivateKey, which made everything click.

jpgoldberg

Well spotted, @analogist!

We will try to fix up our description of the key wrapping in the some future version of the white paper. There are extra layers that can differ from client to client. And you are exactly correct that we really only want to compute the SRP-x once per client, and also provide a key derivation mechanism that is most appropriate for each client and platform.

So yes, there are additional layers of key management for each client that isn't well covered. This is something that should at the very least be make clear in the white paper.

Thanks again!