MUK and Masterpassword and Keysets question
sooooo.... I get that my old master password can be used to unlock my old key set if such a copy existed and I don’t think it does... you don’t have one and you don’t seem to imply that I have it anymore after the change (right). I’m not the target of a nationstate and nobody knew I was downloading u guys that night lol.
Here’s the question , I didn’t use the strongest master password when setting up my account so I wouldn’t lock myself out. Did I inadvertently create a weak muk since it has no bearing on my much stronger current password ? Or does it somehow not matter?
Ty. Hope that makes sense...
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
You win the "forum post subject line that gets rick excited the most" award today! I love being given an excuse to talk about these things.
Let's see if I can answer your question to your satisfaction...
Since you're talking about keysets, I assume you're specifically asking about 1Password.com accounts. Everything I'm about to state applies to accounts, and if I'm making a bad assumption let me know and I'll get you another answer.
What's stored on our server, and what's sent to client apps is your keyset(s), encrypted by the MUK. The MUK (Master Unlock Key for anyone following at home) is the encryption key that's derived from your email address (considered public info), your Master Password, and your Secret Key.
Due to the Secret Key, the strength of the MUK isn't going to vary that much based on your Master Password. A really strong human generated Master Password is estimated to have the equivalent of something like 40bits of entropy. Whereas the Secret Key has 128. So 128 + 40 vs say 128 + 10... it's not significantly different. If the Secret Key was kept secure then it's probably fine.
Let's go over what happens when you change your Master Password in 1Password.com, which happens to be basically the same thing that happens when you regenerate a new Secret Key (both are available to you under My Profile of the webapp):
- The client will make sure that you know your current MP, then prompt you for a new MP.
- The computes a new MUK based on the Email, Secret Key, New Master Password
- Generates a new set of SRP Auth parameters
- Encrypts your current active keyset (the one used to encrypt/decrypt anything you have access to) with the new MUK
- Sends it (SRP Auth params, new encrypted keyset) to the server, encrypted with the current session encryption key
- Our server overwrites the old value in our database
So by changing your Master Password, you changed your MUK, and re-encrypted the keyset with the new MUK.
You're technically right that someone who could get their hands on the keyset, encrypted with the original MUK could decrypt it with the original MUK if they could derive it. The secret key should make that computationally infeasible.
I hope this helps. Let me know if you have any more questions.
Rick
0 -
Lol. No you understood. And it was for accounts. I think perhaps I missread the teams white paper though I have an individual account. Somewhere along the line between white paper and some searching and in the form I thought the MUK remained unchanged. Could be I’m talking about something entirely different that didn’t change after the first creation.... I don’t know... lol irl as I write this.
OT
And referring to the white paper I don’t know anybody who is brave enough to do HtTps pinning for what little extra it gives you... I think last year only something like three or 400 sites were using it. Done badly you brick your business from all old visitors for the next six months....Appreciate ‘the award’ :)
0 -
Somewhere along the line between white paper and some searching and in the form I thought the MUK remained unchanged
The MUK definitely changes, but the keyset does not (currently). The whitepaper does mention the fact that user keysets, group keysets, and vault keys currently don't change over time. The MUK would need to change because the MUK isn't ever stored anywhere. It's something that's derived from other bits of information, and so when one of those bits changes, it too needs to change.
I don’t know anybody who is brave enough to do HtTps pinning for what little extra it gives you
Amen. I quite like the fact that we don't depend on TLS alone to protect the communication. As you said, the risk to reward ratio for pinning has always seemed just too bad to me.
Don't hesitate to send more questions our way. Have yourself a great afternoon.
Rick
0 -
Appreciate the response and let me just rephrase my question and use user keyset instead of muk. Did I goof by using a weak master password and did that play in the creation/derivation of my public/private key. I might be missing it in the white paper, but I would hate the thought of a dumdum error and flaw in using this platform.
Thanks!
0 -
@AlwaysSortaCurious : the user keyset is always created completely randomly generated. Though technically the encrypted form of it was once encrypted using the MUK with the weaker password, due to the extra strength of the secret key i don't think it's a worry.
If you want to be 1000% safe, you could always create a new account though. But I don't think it's really necessary.
Rick
0 -
Thanks. yeah, no one is after me and that old keyset is nowhere to be found. Thanks!
0 -
Anytime.
Rick
0 -
Hi Rick.
That was a great explanation.
Would you please clarify the process of changing the MP and key rolling on standalone primary and secondary vaults?
I have both 1pw.com account and Primary and secondary standalone vaults.
I assume the MUK plays no role with local vaults.
I understand that the Primary vault (not the account MP, if different) will unlock the native client and that the primary vault has escrowed in it, the keys to the secondary vaults.I also understand that changing a local vault's (primary and secondary) MP and creating new local vaults will indeed roll the 256 bit keys.
If I want to change a local vault's MP to make it stronger (not concerned that an attacker has acquired the old key set), would I need to also change the passwords for each individual entry within that vault or will a change of the local vault MP re-encrypt the individual items with the new MP?
I really don't want to go through with arduous process of changing all the passwords for the individual entries within the vaults as I'm not concerned that my original key set has been exposed.
The main reason of course is to create an even stronger MP.If changing a local vault's MP will not re-encrypt the data within the vaults , then would the next best strategy be to create entirely new Primary and secondary vault(s), which would create new keys and then copy contents of the old vault(s) into the new one(s)?
Does copying data into the new vault then encrypt that data with the new vault's MP or would I have to change the passwords for each individual entry since these entries were originally created in an old vault encrypted with an old MP?Again, I'm not concerned that my original key set has been compromised.
What would be the process of restoring the vaults from OPVault files encrypted with the old MP?
I know I would need the old MP for the OPVault files. Once the data has been restored to the new vaults with new MP, will the data be encrypted/decrypted with the new MP?Is there a detailed explanation in the white paper about key rolling for local vaults?
Thanks!
0 -
I assume the MUK plays no role with local vaults.
We don't generally use the term MUK when talking about local vaults, but it has a very similar concept.. it's just much simpler so we don't give it a fancy name. The key that we derive from your local vault's password is equivalent to a MUK. It's the key that decrypts the key that gets you access to data.
I also understand that changing a local vault's (primary and secondary) MP and creating new local vaults will indeed roll the 256 bit keys.
That's incorrect. Changing the a local vault's password only re-encrypts the key for it with the new key derived from the new password. This does not constitute key rolling.
If I want to change a local vault's MP to make it stronger (not concerned that an attacker has acquired the old key set), would I need to also change the passwords for each individual entry within that vault or will a change of the local vault MP re-encrypt the individual items with the new MP?
That's a great question. If you can assume that no one has the old data which was protected by the weaker MP, then just updating the MP would be sufficient. If you can't make that assumption, and that weaker MP was weak enough to cause you concern, then you should assume that someone can use that old data and crack the weak MP. With the old data and old MP, they have the contents of the vault. So it doesn't actually matter whether the contents of the vault are re-encrypted. If an old copy of it which is ultimately protected by a weak key is available to an attacker, they'll go after that and not the new copy protected by the stronger key.
I really don't want to go through with arduous process of changing all the passwords for the individual entries within the vaults as I'm not concerned that my original key set has been exposed.
Depending on your definition of "key set" here, you may not need to do anything. If your old MP was Pretty Strong and you're just going for Very Strong, then I don't think you should worry.
If changing a local vault's MP will not re-encrypt the data within the vaults , then would the next best strategy be to create entirely new Primary and secondary vault(s), which would create new keys and then copy contents of the old vault(s) into the new one(s)?
Correct. That's the right strategy when concerned about the strength of an old key.
What would be the process of restoring the vaults from OPVault files encrypted with the old MP?
I know I would need the old MP for the OPVault files. Once the data has been restored to the new vaults with new MP, will the data be encrypted/decrypted with the new MP?OPVaults are pretty much exactly like the local vault within the local database. Just like the local vault, an OPVault's key does not change over time. No actions cause the complete re-encryption of data within an OPVault. The only thing that would change is the storage of the OPVault key's encrypted form. It would be encrypted with the key derived from the new MP.
Is there a detailed explanation in the white paper about key rolling for local vaults?
The whitepaper is specifically targeted towards 1Password.com and doesn't discuss local vaults.
I hope that answers your questions.
Rick
0 -
Thanks for your reply. That does answer most of my questions.
"...then would the next best strategy be to create entirely new Primary and secondary vault(s), which would create new keys and then copy contents of the old vault(s) into the new one(s)?
@rickfillion "Correct. That's the right strategy when concerned about the strength of an old key."
Please clarify for me the situation with data copied from an old vault into the new vault. (clicking "select all" and choosing "copy/move contents into another vault")
Could that copied set still be decrypted by cracking the old MP even though this set been added (copied) subsequent to creating this new vault with new MP/MUK and new 256 bit key?
Short of creating new username/password entries etc in the newly created vaults, I want to confirm that data subsequently added from an old vault with a weak MP will be protected (or not) with the new MP.
Is this copied data considered an "old copy", as it clearly would be if it remained in the old vault with new MP?
@rickfillion "If an old copy of it which is ultimately protected by a weak key is available to an attacker, they'll go after that and not the new copy protected by the stronger key."The threat model that I'm addressing here is one in which a future attacker would try to brute force crack an old (weak) MP if gaining access in the future but doesn't currently have access and the old vaults with the old, weak MP have been permanently deleted.
@rickfillion "The whitepaper is specifically targeted towards 1Password.com and doesn't discuss local vaults."
I think it would be helpful if there were literature about this topic of key rolling in general and specifically with local vaults as I'm sure it will come up again.
Thanks again.
0 -
The threat model that I'm addressing here is one in which a future attacker would try to brute force crack an old (weak) MP if gaining access in the future but doesn't currently have access and the old vaults with the old, weak MP have been permanently deleted.
Then you should have no concerns beyond just choosing a new Master Password. Unless the attacker has a version of the vault that was protected by the old/weak MP, there is no security concern here (that I can think of).
When choosing a new MP for a vault, there are no more remnants of the old MP anywhere.
I think it would be helpful if there were literature about this topic of key rolling in general and specifically with local vaults as I'm sure it will come up again.
I agree.
Rick
0 -
@rickfillion :When choosing a new MP for a vault, there are no more remnants of the old MP anywhere.
I was under the impression that changing a local vault’s MP changed the MUK only for new data in that vault added subsequently, not the old data still remaining in that updated vault which I thought could still be accessed by the old MP/MUK.
Thank you for clearing all this up for me.
0 -
You're welcome. Let us know if you have any more questions.
Rick
0 -
Hi Rick!
I'll start off by saying that this discussion is generally WAY above my head, but I make it a general rule to try and figure out how the important tools I use in my life work (at a high level, at least). So I went ahead and read 1P's whitepaper as best I could.
I'm a recent migrant from LP, and was evaluating password managers for a bit before deciding on 1P, the other contender being BitWarden. One of the problems with BitWarden was issue BWN-01-010 – Changing the master password does not change encryption keys, identified in their security audit (https://cdn.bitwarden.net/misc/Bitwarden Security Assessment Report.pdf). That issue seems to mirror the keysets question discussed above, and appears to be similar to the topic discussed on page 56 of the white paper, 'Master Password changes don't change keysets.'
Am I correct in looking at these issues as generally similar?
Also, about the mitigation discussed in the 1P white paper, "A user’s personal keyset may be replaced by voluntarily requesting that their account be recovered. This will create a new personal keyset which will be used to re-encrypt all of the vault keys and other items which were encrypted with the previous personal keyset."
Is there any discussion or possibility to request that an option to rotate the user's personal keyset be added to 1P as advanced functionality, for the more paranoid among us (without resorting to account recovery, or even worse, making a new account)? All of the stuff you said previously works for me, really, and I'm not guarding against any crazy, state-actor-level threats. However, if I even THINK there might be a compromise, it would help me sleep better at night.
If it's not in the cards, I can at least be happy that my initial account creation password was pretty robust.
Thanks!
0 -
Yes, those issues do seem similar. In 1Password, changing the Master Password will change the MUK but not the user's keyset. And yes, the recovery process mitigates this by changing the user's keyset.
Is there any discussion or possibility to request that an option to rotate the user's personal keyset be added to 1P as advanced functionality, for the more paranoid among us?
Unlikely, but it never hurts to ask. :) Recovery works because the user doesn't do the whole action, it needs a second actor. An admin starts the recovery process, the user then chooses their Master Password and a new Secret Key is generated, along with a new keypair for the user. The public key, and the encrypted version of the private key are uploaded to the server. But in doing so, the user has effectively lost everything that they had access to as the user doesn't have their old private key. So now you need an admin to complete the recovery, which is the process of taking all of the things the user used to have access to (vaults, groups), and re-encrypting those keys with the user's new public key.
To do this with a single actor so that someone can perform it themselves, we would need to be able to do the whole operation atomically as opposed to doing it in 3 steps. Otherwise if there's an error between when the keys are swapped and when the new access records are uploaded, a user could lock themselves out of their account.
I would rather see us spend the time implementing key rolling for vaults and groups. If you assume the attacker got access to your user's private key, then you should assume that they got access to all of the keys that are encrypted with that private key (i.e. the vault key). Changing the private key stops them from getting new keys, but they'll still have the old vault key and with that they could decrypt data in the vault.
Does that make sense?
Rick
0 -
If I'm understanding this correctly, recovery can work only in the context of a group/shared/family 1P account setting? An individual user (for example, one in a solo plan, as opposed to a family or business plan) would be unable to recover their vaults or previous items after doing a key roll? I'm assuming that a group user can recover because someone else (the uncompromised admin) already has access to the vaults the compromised user needs. Or am I visualizing it wrong?
In either case (I think), it would seem to be an issue that the compromised logins inside the vaults would need to be changed in order to prevent the attacker from getting to them; if you have a significant number of items in your vault, that could be a real pain. I'm not entirely sure how this could be fixed.
As for rolling individual vaults, I'm totally on board with doing anything at all that would harden 1P in general. Password managers are generally the best thing you can use at the moment for managing your online accounts, and I figure it won't be long before they start being targeted en masse, be it via individual users, or the software provider itself. If such attacks already widespread, it's only because a minority of internet users utilize password managers, and there are other, lower hanging fruit around. Trying to get my friends (let alone my elderly parents) to use one is a task I haven't quite mastered.
Forgive me if I've made any grievous errors in thinking through this...encryption isn't the easiest topic to wrap my head around.
0 -
I'm assuming that a group user can recover because someone else (the uncompromised admin) already has access to the vaults the compromised user needs
Correct. The other person has access to the keys.
As for rolling individual vaults, I'm totally on board with doing anything at all that would harden 1P in general.
So are we. :)
Rick
0 -
I started using 1password in 2011 with version 3.9.2. My first master password was not particularly strong. I replaced it with a stronger password a few years ago.
This week I upgraded to v7.4.1 and created a 1password account. Will the vault stored in the new 1password account be protected by the same keyset that was protected by a weak master password back in 2011?
0 -
Hi @00sjsl
Will the vault stored in the new 1password account be protected by the same keyset that was protected by a weak master password back in 2011?
No. Separate keysets. :) When you create a 1Password membership entirely new keys are used. They aren't re-used from your existing standalone vaults.
Ben
0
