---
title: "Data Model"
description: "Infisical's current Data Structure."
---

Infisical stores a range of data namely user, secrets, keys, organization, project, and membership data.

## Users

The `User` model includes the fields `email`, `firstName`, `lastName`, `publicKey`, `encryptionVersion`, `protectedKey`, `protectedKeyIV`, `protectedKeyTag`, `encryptedPrivateKey`, `iv`, `tag`, `salt`, `verifier`, and `refreshVersion`.

Infisical makes a usability-security tradeoff that is to give users convenient access to public-private key pairs across different devices upon login, solving key-storage and transfer challenges across device and browser mediums, in exchange for it storing `encryptedPrivateKey`.

<Note>
  `encryptedPrivateKey` is obtained by symmetrically encrypting the user's
  private key locally with a protected key which is encrypted by the key derived
  from the user's password and salt. Encryption is done via `AES256-GCM` and key
  derivation via `argon2id`. The user's password is not sent to the server —
  this is done with SRP.
</Note>

## Secrets

The `Secret` model includes the fields `workspace`, `type`, `user`, `environment`, `secretBlindIndex`, `secretKeyCiphertext`, `secretKeyIV`, `secretKeyTag`, `secretValueCiphertext`, `secretValueIV`, and `secretValueTag`.

Each secret consists of a key name and value pair and is symmetrically encrypted by the key of the project that it belongs to; that key's encrypted copies are stored in a separate `Key` collection. 

The `secretBlindIndex` enables users to query secrets by their names; it is a blind index computed by applying `argon2id` with a 128-bit random salt (unique to each project) and the name of the secret. The salt itself is symmetrically encrypted under the server key and stored in the `SecretBlindIndexData` collection.

## Blind Index Data

The `SecretBlindIndexData` model includes the fields `workspace`, `encryptedSaltCiphertext`, `saltIV`, and `saltTag`.

Infisical stores salts (unique to each project) symmetrically encrypted under the server key. The salts are used to compute blind indices for secrets that enable
users to query secrets by name.

## Project Keys

The `Key` model includes the fields `encryptedKey`, `nonce`, `sender`, `receiver`, and `workspace`.

Infisical stores copies of project keys, one for each member of a project, asymmetrically encrypted under each member's public key.

## Bots

The `Bot` model contains the fields `name`, `workspace`, `isActive`, `publicKey`, `encryptedPrivateKey`, `iv`, and `tag`.

Each project comes with a bot that has its own public-private key pair; its private key is symmetrically encrypted by the server's key. If needed, a user can opt-in to share their project key with the bot (i.e. Infisical) to give the platform access to the project's secrets.

<Note>
  Sharing secrets with Infisical so they can be synced to integrations like
  Vercel, GitHub, and Netlify is something we make sure users consent to before
  opting in.
</Note>

## Organizations and Workspaces

The `Organization`, `Workspace`, `MembershipOrg`, and `Membership` models contain enrollment information for organizations and projects; they are used to check if users are authorized to retrieve select secrets.

## Service Tokens

The `ServiceTokenData` model contains data for service tokens that enable users to fetch secrets from a particular project and environment; each service token data record includes an (encrypted) copy of the project key that it is bound to as well as a validation hash for `bcrypt`.

## API Keys

The `APIKeyData` model contains data for API keys that enable users to interact with [Infisical's Open API](https://infisical.com/docs/api-reference/overview/introduction); each API key data record includes a validation hash for `bcrypt`.
