What's the surface available to the attacker if the 1password-credentials.json is leaked?
It's reasonable to assume that once the token is leaked, the attacker has full access to the data exposed to the token in question (given the availability of the 1password/connect-api).
What's the attack surface is the connect-api itself is compromised? How much you can do by having the json file at hand?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hi,
Great question. Some background first. The credentials file contains three main pieces, the "encCredentials", the "verifier", and the "uniqueKey".
- The "encCredentials" is an encrypted payload (AES-GCM) that contains all the credentials necessary for 1password/connect-api and 1password/connect-sync to communicate with 1password.com. On its own there isn't anything an attacker can do with it. The decryption key for the credentials file is embedded in the API token so the connect-api/connect-sync processes will only unlock upon first request when it combined the token is used to decrypt the credentials payload.
- The "verifier" is used to validate that the token received in a request is a valid decryption key for the credentials payload.
- The "uniqueKey" is an encryption key that is a shared secret between the connect-api and connect-sync and can be used to encrypt sensitive communications between the two processes.
From an attack surface perspective the risks are:
- If an attacker has the credentials file and a token they can communicate with 1password.com
- An attacker that has only the credentials file but with network access to the connect-api can use the shared secret to impersonate the connect-sync and receive the decryption key to access the 1password.com credentials when the next API request is made.
In the case of compromise deleting the connect server from 1password.com or the CLI will render the credentials invalid.
0 -
Thanks for your detailed explanation!
If an attacker has the credentials file and a token they can communicate with 1password.com
Will that be limited to the vaults exposed for the given leaked token or all the vaults allowed in in environment?
0 -
In the case that an attacker can decrypt the
encCredentialsit would give them the ability to impersonate the environment to 1Password.com and would be able to access any Vaults the environment can access0 -
Let me add that the attacker who gets both the token and the credentials JSON would have the full privileges of the associated service account, irrespective of the claims in the token. But it still is a service account, so unlike a normal user account, it wouldn’t be able to create, share, or manipulate value settings beyond the specific read and write powers for the specific vaults it was set up for.
An attacker who gets hold of the token and has the ability to talk to the Connect sever (but not the credentials file) is limited to what is allowed in the claims portion of the token. Typically, that won’t be more restrictive than what the service account can do, but it can be if you create it that way.
When working with the credentials file for, say, creating a token or setting up your Connect server, you may wish to do so in a temp directory that is not backed up. That way it is led likely to find its way into places you don’t expect.
0
