Does the last Cure53 audit imply that a secret change is not safe if your RSA key is compromised?
The latest Cure53 audit of 10.2020 states the following:
It was found that changing the master password for the 1Password vault does not reset its underlying RSA key-pair. The latter provides the set of secret keys used to encrypt individual vault items. Therefore, this flaw means that in the event of a vault RSA key compromise (to which multiple vectors are offered through 1PW-01-015), it is impossible to restore the vault to a “safe” state.
I assume this means that a compromised key pair will allow an attacker to get into your account even though you have changed the password. The report does not mention a changed secret key. In this example, if you update your secret key, is the underlying RSA key-pair reset?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
@wesleynroberts - no. You can find more about this in our 1password.com security white paper, specifically page 56, "Master Password changes don't change keysets".
Currently, the simplest method of ensuring a keypair change is to have someone else on the team put you through the recovery process.
0 -
Maybe I misunderstood, but does the RSA keypair only apply to team accounts?
Is this an issue for individual accounts, and, if so, how would you change the keypair?
0 -
Maybe I misunderstood, but does the RSA keypair only apply to team accounts?
Sorry for the confusion. No, it applies to any account since the architecture is the same. And you're quite right to observe that the option of recovery isn't available to those using an individual 1Password account. Compromise of the keyset would be an unlikely thing regardless of account type, but if you have an individual 1Password account and believe it has occurred, your remedy would be to create a new account and either move all the data out of the existing one into the new one by export/import or by direct move within a 1Password application, then closing the older account.
0 -
Lastly, how might an attacker get your keypair? Does the private key live locally, and thus the attacker would have to have access to my local machine?
I will skim through the white paper this weekend. Thank you.
0 -
@wesleynroberts - yes. The private key only exists on your local device; an attacker would need either direct physical access or remote compromise of your device in order to acquire it, or a similar compromise of an internet-based backup if you do such things via Crashplan or Backblaze, etc. Remember, the attacker would also need to decrypt the key, which would require possessing - or being able to acquire, or brute-forcing - your account's Master Password and Secret Key. The latter (brute force) is made computationally infeasible by the length of the Secret Key. If you assume that compromise of your local device means acquisition of the Secret Key -- which is a reasonable assumption, given a competent attacker, then it's down to the strength of your Master Password, which is why we consistently urge users to choose a good Master Password.
There's an older discussion here that goes into greater detail, if you're interested, and the white paper is always a great - if involved - resource.
0 -
@Lars - It seems to me that a more preferable way to use RSA key pairs would be to designate a vault to be shared and generate a key pair for it only, or something equivalent to this.
That way the rest of one's database would be encrypted solely with 256 bit keys, independent of any RSA keys.
1password's current architecture provides security to one's entire database at a level of 112 bit (2048 RSA) rather than 256 bit, for the sole purpose of sharing, regardless if one is an individual, who has no need to share vaults, or a family member who needs to share only certain vaults.
Yes, brute forcing or breaking a 2048-bit RSA key is currently believed to be impossible but people are expecting and paying for the security margin afforded by 256 bit level encryption, not 112 bit.
This is especially true since we are storing data on your servers and soon will not have the option of using local vaults.0 -
Thank you for the feedback here! I had the chance to discuss this with our security team and, while there are no plans to make changes here at this point in time, I was given a link to a post here on the forum from our Chief Defender Against the Dark Arts that adds some details about these choices. You can find it here :+1:
0
