15 Server Infrastructure

15.1 What the server stores

1Password stores account, team, vault, and user information in a relational database. Membership in teams and access to team resources, including vaults, groups, and items, are determined by fields within each database table. For example, the users table includes three fields used to determine user identity and team membership. These fields are uuid, id, and account_id. The user’s account_id field references the accounts table id field, and this relationship determines membership within an account.

These relationships — users to accounts, accounts to vaults, vaults to items — don’t determine a user’s ability to encrypt or decrypt an item, they only determine the ability to access the records. The relationship from a user to an item within a team vault is as follows:

  • A users table entry has an account_id field that references the id field in the accounts table.

  • An accounts table entry has an id field which is referenced by the account_id field in the vaults table.

  • A vaults table entry has an id field which is referenced by vault_id field in the vault_items table.

  • A vault_items table entry has the encrypted_by, enc_overview, and enc_details fields which reference the required encryption key and contain the encrypted overview and detail information for an item.

A malicious database administrator may modify the relationships between users, accounts, teams, vaults, and items, but the cryptography will prevent the items from being revealed.

Principle 3 states the system must be designed for people’s behavior, and that includes malicious behavior. A malicious database administrator may be able to modify the relationships between users and items, but he will be thwarted by the cryptography when he, or his cohort in crime, attempts to decrypt the item. The cryptographic relationship between a user and an item within a team vault is as follows:

  • A vault_items entry has a vault_id field which references the vault_id field in the user_vault_access table. The enc_overview and enc_details fields in a vault_items entry are encrypted with the key contained in the enc_vault_key field of the corresponding user_vault_access entry, which is encrypted itself.

  • A user_vault_access entry is located using the id field for the users table entry and id field for the vaults table entry. The enc_vault_key field in the user_vault_access entry is encrypted with the user’s public key and may only be decrypted with the user’s private key.

  • A users entry is located using the email address the user provided when signing in and the accounts entry for the matching domain. The users entry includes the pub_key field which is used to encrypt all the user’s secrets.

With the hard work of the malicious database administrator, the user may have access to a user_vault_access table entry which has the correct references, but since 1Password never has a copy of the unencrypted vault key, it’s impossible for the user to have a copy of the vault key encrypted with her public key. The malicious database administrator could copy the encrypted vault key for another user, but the user wouldn’t have the private key required to decrypt the encrypted vault key.

Principle 2 states we should trust the math, and as has been shown here, even if a malicious database administrator were to modify the account information to grant a user access to an encrypted item, the user still lacks the secrets needed for decryption. The attacker has been foiled again.

Finally, principle 4 states that our design should be open for review. While we hope our database administrators don’t become malicious, we’ve provided all the information needed to grant unauthorized access to encrypted items knowing they will remain protected by cryptography.

The example of a malicious database administrator was chosen because the worst-case scenario is someone sitting at a terminal on the back end server, issuing commands directly to the database, with a list of database tables and column names in hand.

15.2 How your data is stored

1Password stores all database information using an Amazon Web Services Aurora database instance. The Amazon Aurora service provides a MySQL-compatible SQL relational database. Aurora provides distributed, redundant and scalable access. Some of the tables and their uses were provided earlier.

Data is organized in the traditional manner for a relational database, with tables consisting of rows and columns,33 with various indices defined to improve performance.

Binary data, which may include compressed JSON objects representing key sets, templates, and other large items is compressed using ZLIB compression as described in RFC 1950.

The tables are listed as follows:

  • accounts Contains registered teams, which originated from an initial signup request, approval, and registration. This table includes the cleartext team domain name (domain), team name (team) and avatar (avatar). Other tables will typically reference the accounts table using the id field.

  • groups Used to reference groups of users in a team. The groups table is primarily referenced by the group_membership and group_vault_access tables. This table includes the cleartext group name (group_name) and description (group_desc), public key (pub_key), and avatar (avatar).

  • invites Contains user invitations. The unencrypted acceptance_token is used to prevent inappropriate responses to an invitation and not relevant once a user has been fully initialized. The remaining unencrypted columns are the user’s given name(first_name), family name (last_name) and email address (email).

  • signups Contains user requests to use the 1Password server. This table includes the cleartext team name (name) and email address of the requester (email).

  • users Contains registered users, which originated via the invitation process and were eventually confirmed as users. This table includes the cleartext user name (first_name and last_name), email address (email), a truncated copy of the lower-case email address (lowercase_email), the user’s public key (pub_key), and an avatar (avatar).

Aggregating the list of unencrypted fields above, the data subject to disclosure in the event of a data breach or required disclosure are:

  • Team domain name, long-form name, and avatars.

  • IP addresses used by devices

  • MFA secrets

  • Client device makes, models, operating systems, and versions

  • Public keys, which are intended to be public.

  • Group names, descriptions, and avatar file names.

  • Users’ full names, email addresses, and avatar file names.

  1. Only the cleartext columns will be listed at present as these are the columns which would be disclosed in the event of a data breach. The encrypted columns will be protected by the security of the various keys which the server doesn’t possess.↩︎