What information can be derived from the item link url scheme?

leedxw

I've been asked if it's safe for teams to embed direct item links in documentation that, while only intended for internal use, will be publicly available on the internet.

i.e. the concern is not so much with credentials, as it is the possibility of information such as vault names, leaking.

https://start.1password.com/open/i?a=XXXX&v=YYYY&i=ZZZ&h=VVV.1password.com

In the URL scheme we accept that the account name in h will be public, but it's not clear if the values in a, v, i can be used to discover additional information without logging it to 1Password. Are these values completely meaningless without account access?

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

rudy

@leedxw,

a is the UUID of the account
v is the UUID of the vault within that account
i is the UUID of the item within that vault
h is the hostname for the team

without an account + secret key + master password those bits of information aren't particularly useful. I can ask someone from the security team to comment further if you'd like.

leedxw

I suppose the question I would ask the security team: are there any implications in UUIDs for accounts, vaults, and items being known. Are there any assumptions made on the basis that knowledge of UUIDs wouldn't be expected beyond authorised users?

leedxw

Also, if a encodes an account identifier, how is the value of h used? Is mapping of account to domain not one-to-one?

rudy

@leedxw,

The reason that both the account UUID and the host are included is because the your team could be on 1Password.com, 1Password.eu or 1Password.ca. While a UUID is meant to be globally unique, there is a non-zero, but highly unlikely possibility that those UUID might exist on the other environments, so the host parameter aids in resolving that to an exact domain within the environment.

jpgoldberg

@leedxw, let me add to Rudy's answer.

We designed the use of these UUIDs specifically to have no information about a vault or item. They are created randomly when the account, vault, or item is created. These are the "metadata" are transmitted unencrypted (other than by TLS). They were deliberately designed to contain no information in and off themselves. They don't correlate to creation time or creation system or anything like that. They are just 16 random bytes (128 bits). This is because we wanted to draw a sharp line between what we needed to protect and what we couldn't protect (other than by TLS).

They are, however, identifies. So if you use one of these links for the same item more than once, someone can tell that you are talking about the same item. If you post multiple links to different items in the same vault, then people will be able to see that you are talking about items in the same vault. So someone able to engage in a great deal of traffic analysis might be able to guess how your vaults are organized. Keep in mind they won't know anything else about the vaults or items.

Account names are not presumed to be secret. Although you can't learn an account name from the UUID for it, there are too many places where account names are communicated over channels that we can't fully protect.