Data security

Uses: Insomnia

Insomnia implements end-to-end encryption (E2EE), which means that all encryption keys are generated locally, all encryption is performed before sending any data over the network, and all decryption is performed after receiving data from the network. At no point in the sync process can the Insomnia servers, or an intruder read or access sensitive application project data.

Insomnia data is stored in a pooled model for multi-tenancy. Each row is separated by a tenant identifier within the database. To retrieve data, the Insomnia Admin API request must have the tenant identifier (organization ID) in the request path and an authenticated user who is a member of the target tenant (organization).

Sign up and authentication

Insomnia uses the Secure Remote Password (SRP) protocol to securely manage authentication without sending or storing passphrases in a readable format. This ensures that sensitive user credentials remain protected during account creation and login.

Account creation

During sign up, the client generates encryption keys, salts, and RSA key-pairs. It derives secure password representations using HKDF and PBKDF2 and encrypts sensitive keys before sending them to the server. The server stores only the SRP verifier and encrypted data, never the raw passphrase.

Account login

When logging in, the client repeats the password derivation steps and performs an SRP exchange using stored salts. A session key is then generated and used for encrypted communication, ensuring the passphrase itself is never exposed.

Data models

The following are data models we use.

Data Model

Definition

M_Account A user that can log in
M_Resource An entity that can be synced (e.g. Request, Workspace, etc.)
M_ResourceGroup A group of M_Resource that can be shared as one
M_Link A relationship linking a M_Account to M_ResourceGroup

Keys and salts

The following are keys and salts we use.

Name

Definition

Stored?

Stored with encryption?

PUB_Account Public key for M_Account Y N
PRV_Account Private key for M_Account Y Y
SYM_Account Symmetric key for M_Account Y Y
SYM_ResourceGroup Symmetric Key for data encryption N N
SYM_Link Encrypted form of SYM_ResourceGroup Y Y
SLT_Auth_1 Salt for PBKDF2 of passphrase for auth Y N
SLT_Auth_2 Salt for SRP authentication process Y N
SLT_Enc Salt for PBKDF2 of passphrase for encryption Y N
SEC_PWD_Auth Secret derived from passphrase using SLT_Auth_1 N N
SEC_PWD_Enc Secret derived from passphrase using SLT_Enc N N
SRP_Verifier Verification string used for SRP Y N

FAQs

All data is encrypted using randomly generated 256 bit symmetric keys for use with AES-GCM-256 (Galois Counter Mode).

Information is sent over TLS and is end-to-end encrypted.

Secure Remote Passwords (SRP) encrypted key exchange protocol. You can read more about the exact SRP implementation that Insomnia paid plans use in RFC-2945.

Information is stored in GCP, within Postgres, in US Central region.

Insomnia requires users who use cloud or git sync storage to have a passphrase to decrypt their account keys.

If you lose your passphrase, there is no way to access your account projects and information and your account must be reset. If you have been invited to collaborate with other organizations, you can reset your passphrase and then ask to be invited back. You will only be able to retrieve data for the organizations that you are invited back to. If you have shared your personal organizations or project data, you can ask other users with Admin permissions to also re-invite you after resetting the passphrase.

Local data is not encrypted on disk. Insomnia currently stores application project data locally on disk in raw form. E2EE only applies to project data that is transmitted over the network. It is still possible for malicious software to access the project data stored on your machine. Please take the usual precautions to keep your local project data safe.

No. Insomnia allows you to choose if you want to use AI for certain features, like generating tests. Data you provide to use these AI tools are not end-to-end encrypted and so this document does not apply to such data.

The ability to share Resource Groups is the reason that every Resource Group needs its own key, and every account needs a public/private key-pair to securely share said key. Here’s an example involving two users, Jane and Bob. For Jane to share a Resource Group with Bob, she must encrypt the Resource Group’s key with Bob’s public key and store it on the server (M_Link). Now, Bob can use his account’s private key to decrypt the Resource Group’s key and gain access to the data. This is a classic example of the Diffie-Hellman key exchange being put to good use.

Something wrong?

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!