7 How items are shared with anyone
As described in “How vaults are shared securely,” sharing items among members of the same 1Password account happens at the vault level But it’s also possible to securely share a copy of individual items with individuals who are not members of the same 1Password account or even 1Password users at all. The mechanism, however, is entirely different, largely because the recipient can’t be expected to authenticateThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. in the same way as a 1Password user would, and the recipient doesn’t have a public key the sender can use.
The 1Password item sharing service allows a 1Password user to make a copy of an item available to anyone, whether the recipient is a 1Password user or not. In this section we’ll often follow user documentation and the user interface in calling this “sharing,” but we we’ll also write in terms of sending and receiving to help accentuate the distinction between this mechanism and the sharing of vaults.
7.1 Overview
There are six components to the overall picture.
1Password client The 1Pasword application with which users directly interact. This includes not only applications such as the 1Password iOS app, but also the web client and browser extensions acting as a client. We we’ll sometimes refer to this as “the sender’s client.”
1Password service The principle 1Password service.
Item sharing servive The share service which, among other things, will store the encrypted shared copies.
Item sharing client The share web client. It operates in the recipient’s browser and is downloaded from the item sharing service. We’ll sometimes refer to this as “the recipient’s client.”
Sender The human interacting with their 1Password client.
Recipient The human interacting with the item sharing client.
Figure 7.1 illustrates which components talk to which. In particular, the 1Password client communicates only with the sending user and 1Password service. The 1Password server communicates with the item sharing service. Item sharing client communicates only with the receiving user and the item sharing service. And the sender will communicate directly with the recipient outside of 1Password using a communication channel of their choice. Additionally, the figure shows the encrypted copy of the item and key, and that their decryptions follow different paths.
Figure 7.1: Item sharing, key, and token flow. The solid purple arrows show the flow of the encrypted item, solid red arrows show the flow of the encryption key, and dashed green arrows show the flow to the retrieval token. “IS Server” and “IS Client” refer to the item sharing server and client. Item encryption and decryption can only occur where the key and the item are together, which is at the clients. The share token is used for authenticating a download of the encrypted item by the item sharing server.The 1Password and item sharing servers never have access to the share key. This figure doesn’t include flow of audit and share status information.
7.2 1Password client
The sender’s client needs to do two things: create a share link and upload an encrypted copy of the shared item to the 1Password service. The sender also needs to transmit the share link to the recipient independently of 1Password services.
7.2.1 Making a share link
The share link looks something like what is shown in Figure 7.2.
Figure 7.2: A share link is a URL that contains in its fragment information required to identify the shared item, along with the key necessary to decrypt it.
At a high level creating the share link involves five steps performed by the sender’s client.
- Obtain the user item to be shared and decrypt it. The item must be something the sender can read and decrypt, and the sender must also have other appropriate permissions for the vault.
- Create a public unique identifier, a retrieval token, and an encryption for this share.
- Encrypt a copy of the item with the share key.
- Upload the encrypted data to the share service along with the identifier and sender chosen access options.
- Present the sender with the share link.
As always, the key generation, encryption, and creation of the share link are performed entirely on the sender’s client. The 1Password service never has access to the decryption keys nor the decrypted item.
7.2.2 Client’s first steps
The requirements of step 1 involve a number of mechanisms. The requirement that the sender be able to decrypt the item is cryptographically enforced, as they would never be able to re-encrypt anything they cannot decrypt. Additionally, the client will only present the user the option to share if the sender has the appropriate vault permission (detailed in the description of the upload step).
Figure 7.3: 1Password client gets information from sender
The sender is presented with certain configuration options including whether recipients need to demonstrate control of certain email addresses, the required email addresses if any, the amount of time the shared item should be available, and how many times the recipient can retrieve the item. These options will play a role in the retrieval process. The client will check whether the options are consistent with account policy at this time.
7.2.3 Encryption and key generation
In step 2, the client generates 32 random bytes to be the share secret. The 32-byte encryption key, the 16-byte public Universally Unique Identifier (UUID)A large arbitrary identifier for an entity. No two entities in the universe should have the same UUID., and the 16-byte retrieval token are derived from the share secret using hash-based key derivation function (HKDF)A key derivation function that uses HMAC for key extraction and expansion. Unlike PBKDF2, it’s not designed for password strengthening. as detailed in Figure 7.4.
Figure 7.4: Creating shared IDs and secrets. The client generates a share secret, from which it derives an encryption key, a public UUID, and a retrieval token.
The first part of step 3 involves making a copy of the item to be shared. The copy is identical to the one remaining in the vault except that attachments and password history are removed. The existence of attachments and password history in an item may not always be salient to the sender, and so those are excluded from the copy. The copy is then encrypted using the identical methods used for encrypting items in vaults.
7.2.4 Uploading the share
In step 4, the client uploads the encrypted item along with the public UUIDA large arbitrary identifier for an entity. No two entities in the universe should have the same UUID. and the retrieval token to the 1Password service. The service will reject the request unless sending items is allowed by account policy; the recipient specification is consistent with account policy; and the sender has read, reveal password, and send item permissions for the vault containing the original item. The share secret, which contains the the share key, is never passed to the service. Additionally, the UUID of the vault and specific item are uploaded, along with the version number of the vault. This metadata allows the user and vault administrators to manage shares. Account policies can specify whether share retrievals must be tied to recipient email addresses and whether those are limited to specific email domains.
The configuration options selected by the sender are also part of this upload. The server will check whether they’re consistent with account policy (whether retrieval is restricted to people with particular email addresses) and whether the email addresses conform to that policy. Additionally, the server will ensure the availability time requested by the client doesn’t exceed server or account policy. Upon success, the server responds with the non-fragment part of the share link. In current configurations, this is https://share.1password.com/s.
After a successful upload, the client will present the user with the share link (step 5).
Figure 7.5: 1Password client presents item sharing share link.
The client appends the share secret (base64 encoded) as a fragment to the URL returned by the server. The fragment in the share link contains the share secret from which the retrieval token and encryption key are derived, and therefore must not be transmitted to intended recipients via the 1Password service.
The share link places the identifier and the decryption key within a URL fragment. In general fragments are never transmitted and are used solely by the clients as additional information on handling the retrieved resource. By putting the share secret in the fragment, we not only prevent ways in which the secret could be exposed, but we also make it clear this is a purely local secret.
At a superficial level, it may appear that placing the item identifier within a fragment is a minor abuse of the standards defining URLs. The non-fragment part of a URL is supposed to fully identify the resource to be retrieved, while that portion of our share links only identifies the 1Password share service. Fragments, however, are also intended to provide information to the client about handling or further processing the retrieved resource, and this is exactly how we use the fragment. Thus our fragment, even with its inclusion of a resource identifier, may be closer to the spirit of the standards than would be including it within the path or a query string. In any event, we don’t anticipate the IETF to send an enforcement squad to our door for our use of fragments.
7.3 Server to server
The 1Password service is responsible for passing the share to the item sharing service. The 1Password service communicates with the item sharing service using our inter-service communication architecture;10 the item sharing service is hosted at share.1password.com and is a separate service despite being in a subdomain of 1password.com.
The item sharing server itself is hosted in the European Union, despite the .com top-level domain. This same EU-based service is used by all 1Password servers, including those in the United States and Canada. This way, recipient email addresses – as they are passed from 1Password server to item sharing server – never leave the European Union.
The 1Passsword server passes to the item sharing service what it received from the sender’s client, along with information about the authenticatedThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. user and account, it adds its own timestamp, and the number of seconds the item is to be available to the current time to create an expiry time.
7.3.1 Audit and status queries
The 1Passsword server has the ability to query the item sharing service about the state of existing shares. The queries identify items by their account, vault, and item UUIDA large arbitrary identifier for an entity. No two entities in the universe should have the same UUID.. As discussed in far too much detail in Discussion 2, UUIDs are never expected to be secret, so guaranteeing the requests are authorized cannot depend on knowledge of those UUIDs. To ensure only authorized individuals are able to see the status or audit events regarding a share:
- These queries are performed over the same mutually authenticated channel not described in Note 11.
- The 1Passsword server ensures the account identifier in the query is honest.
- The 1Passsword server has the responsibility to ensure the authenticated user creating the request is authorized to make such requests for that account.
7.4 Share pickup
When the recipient follows a share link, their browser will fetch the page at https://share.1password.com/s. The browser won’t transmit the fragment containing the share secret. The page contains a item sharing web client, software that will run within the user’s browser on their own device. The item sharing client running within the user’s browser is, however, able to see and make use of the fragment portion of the share link, and thus will have the share secret.
The client uses the share secret as detailed in Figure 7.4 to derive three things:
Share key The share key is the symmetric key that was used to encrypt the item and is necessary to decrypt it. This key is never made available to any 1Passsword service.
Share token The share retrieval token is a secret that is shared between the user and the share service.
Share UUID The share UUIDA large arbitrary identifier for an entity. No two entities in the universe should have the same UUID. is a non-secret record locator used by the share service to locate the item in its data store.
The item sharing client will send a request to the share service requesting the share by UUID. The share token is passed to the item sharing server in an HTTP header OP-Share-Token, as is the norm for bearer tokens. Neither the share secret nor the share key are ever sent to the service.
There’s some duplication between the UUID and the share token. The share token is sufficient to uniquely identify the share, and knowledge of the UUID offers the same proof of receipt of the share link as knowledge of the share token does. The fact that we don’t combine both of those functions into a single value provides an opportunity to explain a design principle throughout 1Passsword.
In the United States, Social Security Numbers (SSNs) were never designed to be secrets they were unique identifiers. But in the second half of the 20th century, banks offering services by telephone began to take knowledge of a caller’s SSN as proof of identity. Most systems continued to treat SSNs as non-secrets for a very long time, and changing those systems has proved to be enormously difficult. Credit card numbers followed a similar story with the advent of telephone shopping.
Co-opting knowledge of account or personal identifiers for authentication must have seemed like an easy strategy at the time. We’re still plagued with the consequences half a century later.
Throughout the design of 1Passsword we have insisted that knowledge of a UUID must never be used as an authentication mechanism. This not only gives us the freedom to design protocols in which UUIDs never have to be kept secret, it also means we don’t have to worry about future uses. At the moment, share tokens and share UUIDs pass through the same hands and over the same channels, but there may be a time when we use or log UUIDs in ways that would be inappropriate for share tokens or require new security properties of share tokens. By holding ourselves to our design pattern now, we prevent a substantial category of security bug in the future.
The item sharing service will first check the validity and existence of the UUIDA large arbitrary identifier for an entity. No two entities in the universe should have the same UUID.. A malformed or unknown UUID will result in an error response to the item sharing client. If the UUID is valid, it then compares11 the share token with what it has stored. If no further authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. is required, it returns the encrypted item to the item sharing client, which can then use the share key to decrypt the item and render it for the recipient.
The item sharing server creates and stores an audit event record for a successful access. The audit record includes identifiers for the share and the accessor as well as the IP address and HTTP user agent of the and item sharing client. For business accounts, audit events are available to the mangers of the account from which the item was sent.
7.4.1 Additional authentication
In all cases, the item sharing client needs to provide the server with the share token and will need have the share key to be able to decrypt the share, but there may be additional authentication requirements. At the present time, additional authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. is based on control of email addresses.
Figure 7.6: Item sharing client item view.
In the case that email authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. is required, the share recipient (or their client) needs to either prove they can read email sent to the specified email address or prove it has previously offered such proof. In the first case, the share recipient is offered to have a verification email sent to the address associated with the share by the sender. The email will contain a randomly chosen six-digit verifier the user can enter into the item sharing client, which will send the item to the item sharing server.
After successful email verification, the server will issue an accessor token to the client, which the client will write to its local storage. For future share retrievals, the client can provide this access token to show that it has previously succeeded with email verification.
7.4.2 Client analytics
The item sharing client may offer its user buttons for signing up for 1Password, saving the item in 1Password, or accepting an invite to join the team from which the item was sent. Clicking those buttons will trigger a request to the item sharing server which is used to keep count of such clicks. Only overall and aggregate counts of the triggering events are saved server side.
7.5 Caveats
The item sharing service is intended to share copies of items with individuals who are not members of the 1Passsword family or team in which the original item resides. Within team or family accounts, sharing offers security properties which sharing via item sharing cannot.
Within an account, a relationship can be established between the personal key setsHow collections of keys and their metadata are organized within 1Password. of the members of accounts. But when sharing outside of an account, there’s no preestablished relationship that can be used to identify the sender or the recipient. For this reason, item sharing senders and recipients need to take more care to verify independently that the other party is who they say they are.
When the recipient is given a share link through some channel, 1Passsword can’t tell them whether the person sending the share link is the person who created the share link. Similarly, email authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. only proves the recipient had the ability to read an email message sent to that address at some time. Without the shared item remaining a single item shared within an account, there’s far less ability to manage, control, or monitor use of that item as there would be within a team.
The identification of the item shared is entirely under the control of the sending client and can’t be enforced by the 1Passsword server. A sender can evade the policy controls about which items they are allowed to send in much the same way a user can evade other client enforced permissions, such as having the ability to reveal a password. Thus a malicious user with the skills to modify their own client can share any item they’re capable of decrypting by telling the 1Passsword server that some other permissible item was shared.
In practice, the channels over which the share link is transmitted lack the ideal security properties but they may well be sufficient for the needs at the time. Item sharing is safer and more convenient than the practical alternatives available to most users. In particular sharing with item sharing offers the ability to:
- Set an expiry time on the share.
- Limit the number of times it can be retrieved from the 1Passsword server
- Restrict retrieval to holders of a specific email address.
- Track what has been shared.
- Have policies stating what’s allowed to be shared.
These abilities create a substantial security improvement against the practice of simply sharing unencrypted data over the same channels one would use for sending the share link.
We offer the item sharing service because it’s enormously more secure than other ways people find to share 1Passsword items outside their family or team. After all, any 1Passsword user in a position to decrypt an item already has the ability to make a copy of its data and transmit that in any form of their choosing. Item sharing can’t prevent insecure sharing, but it makes it easier for people and organizations to share copies of secrets in a more secure manner than they may otherwise.