Security Brief

TLDR

Infisical uses end-to-end encryption (E2EE) to securely store and share secrets. It uses secure remote password (SRP) to handle authentication and public-key cryptography for secret sharing and syncing; your secrets are symmetrically encrypted at rest by keys decryptable-only by intended parties in your team. Unlike some competitors in the space, we've put measures in place so that secrets remain your-eyes-only - all while making minimal user-experience trade-offs.

Background

Infisical uses E2EE to securely store and help users share secrets; our ability to instantly sync your team’s secrets in seconds whilst being secure with E2EE is precisely the difference between our service and others that make trade-offs between user experience and security. More specifically, comparable alternatives are typically not E2EE and thus the blast radius of any associated breach is far greater; if their service is compromised then so are your secrets. This bears stark contrast to our system where our hope is to keep the secrets away from even our eyes despite holding them for you; we believe that your secrets are in safer hands when they cannot be read by ourselves — even if our service is compromised then your secrets are still safe because you are the only ones who can decrypt them locally; we’ll go over all of this in a bit.

Our security model spans sensitive data stored on the server-side and in transit between user devices; we do our best to secure client-side data but make no security guarantees for malicious events that can occur beyond our control such as user-device security exploits or key-logging arising from poor cybersecurity management on the users’ behalf.

For this security brief, we refer to users uploading their secrets to the server-side as “senders” and those receiving secrets as “receivers.” Collectively, senders and receivers are roles assumed by members of a shared workspace such that, depending on the context of uploading or receiving, a member can be either a sender or a receiver. For instance, if Bob and Alice are both enrolled in a shared workspace and Bob pushes new secrets to the workspace to be pulled by Alice, then Bob is considered to be the sender and Alice the receiver.

We use AES256-GCM for all symmetric encryption and x2519-xsalsa20-poly1305 for asymmetric encryption operations mentioned in this brief; key generation and asymmetric algorithms are implemented with the TweetNaCl.js library which has been well-audited and recommended for use by cybersecurity firm Cure53. Lastly, our secure remote password (SRP) implementation uses jsrp package for user authentication. As part of our commitment to user privacy and security, we aim to conduct formal security and compliance audits in the following year.

Data Model

To begin, Infisical collects and stores a range of data namely user, secrets, keys, and workspace and membership data. Respecting our stance on E2EE, all data that needs to be E2EE encrypted is done so locally before leaving users’ devices and only then stored with us. Let’s dive into each one:

The user collection includes fields like names, emails, public keys, encrypted private keys, and various authentication identifiers. We make a usability-security tradeoff here 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 us storing your encrypted private keys. In any case, private keys are symmetrically encrypted locally by user passwords which are not sent over to the server and thus not stored in the database upon signup — more on how we achieve password-less authentication using SRP later.

Currently, Infisical stores secrets under three related collections which we intend to spread across different databases in the future: secret pairs, secret keys, and secret values. The secret pairs collection connects the other two collections and specifies the key type (shared/personal); the latter intent specifies whether the key is accessible to all members of a workspace or just the member who uploaded it. The secret keys and secret values collections are both symmetrically encrypted by a workspace key which is duplicated and encrypted by the public key of each member in the workspace, and uploaded to the server together; the keys are stored in a separate collection. Put differently, every secret key and secret value is encrypted by a workspace key where there are multiple workspace keys for each member of a workspace.

Lastly, the workspace and membership collections include workspace names and enrollment information; we use this collection primarily to organize and handle access management (i.e. ensure that the right people and files are associated with and have privileges to the right workspaces).

Mechanism

Upon signing up for an account, users confirm their email addresses, generate public-private key pairs to be stored locally (private keys are symmetrically encrypted by the users’ newly-made passwords), and forward user identifier information to the server that is their emails and names. Infisical authenticates users using the secure remote password (SRP) protocol as opposed to traditional authentication techniques that expose passwords to servers and are more vulnerable to dictionary attacks; with SRP, servers can authenticate users without knowing their passwords by sending information back and forth with clients to mutually derive shared keys — we plan to also reinforce the authentication mechanism with optional two-factor authentication in the near future (2FA). Note that SRP demands that we send salt and verifier information, generated from the user’s key, to be stored on the server-end but that this is not equivalent to storing the user’s password; the salt and verifier are used only as part of SRP to derive and verify shared keys for future authentication. Once authenticated via SRP, Infisical issues JWT and refresh tokens to authenticate user sessions; tokens are stored in HttpOnly cookies to side step potential XSS attacks on local storage.

After signing up, users invite their teams to Infisical to partake in the shared workspace; email-based invitation links ensure that only designated team members can confirm their identity and are added to the right workspace. Once ready, teams begin by uploading a .env file to the workspace either by dragging it onto the web application or using the “npx infisical push” command similar to that of git; once pushed, recipients are notified of this update and can start syncing the secrets using the auto-pull and inject mechanism or the “npx infisical pull” command. We refer to the previous actions as the “push” and “pull” operations. Whether it be at rest on the server or in transit, secrets data is always encrypted (secrets symmetrically encrypted by a workspace key that is asymmetrically encrypted by members’ public keys as previously described in the data model). in most cases, users will use the auto-pull and inject mechanism which prevents environment variables from being stored in plaintext format on users’ machines. The only case where we don’t encrypt .env files is when users explicitly wish to maintain a local .env file using the “pull” operation for their apps to access the environment variables.

We think about the secrets encryption, storage, and sharing process in two stages that is the “push” and “pull” stages which are used both in the web application and CLI. To push, senders randomly-generate a symmetric encryption key, use that key to encrypt their secret keys and values separately, asymmetrically encrypt the key with the receivers’ public keys, and upload the encrypted secrets and keys to the server; conversely, to pull, a receiver obtains encrypted secret keys and values and their encrypted copy of the workspace key to decrypt the secrets from the server — they asymmetrically decrypt the key using their private key and use the decrypted key to decrypt and read the secrets. At rest, secrets stored on the server-side are, as stated, symmetrically encrypted by random keys generated locally by senders; the keys are duplicated for each designated receiver, encrypted by that receiver’s public key, and then stored on the server. This means that an encrypted secret pair in a workspace can have multiple unique encrypted access keys intended for a select group of users in a workspace; only those users can decrypt their copy of the key to in turn decrypt secret pair. The secrets are encrypted the same way in transit. Additionally, it should be noted that all secrets are signed by senders so that their authenticity and integrity can be verified on the receivers’ end — authenticity is also built into JWT tokens which identify every user session; this prevents bad actors from impersonating team members and being able to alter data in workspaces that they don’t belong in.

The aforementioned public-key mechanism makes it infeasible for bad actors or even Infisical to read any secrets even though we store them; to do so would require one to possess either knowledge of a user’s password (which can be used to decrypt their private key) or their private key and even then he/she wouldn’t be able to decrypt other workspaces’ secrets on the server — this is great because it minimizes the blast radius of any potential breach.

Commitment

As a secrets manager, we are committed to enforcing the privacy and security of all users and data on the platform but acknowledge that it is virtually impossible to guarantee perfect security; unfortunately, even the most secure systems have vulnerabilities. In fact our commitment is the very basis for our decision to make the platform E2EE; we believe that if we cannot even decrypt your secrets then it is necessarily safer in the catastrophic event of a breach as bad actors would be unable to decrypt your secrets either. As part of our commitment, we do our best to maintain platform privacy and security, notify users if anything goes wrong, and rectify adverse situations immediately if it ever happens. As our company grows, we will be adding more opt-in security measures to ensure better data protection and continuous trust of our growing client pool; we will also produce a fuller security whitepaper and specification in the future. With that, let’s make the most simple and secure secrets management system out there!

Best,

Infisical Team