Security Architecture

Envault prioritizes security above all else. Our architecture is designed to ensure that your secrets remain confidential, even in the event of a database compromise. We adhere to the principle of Defense in Depth.

Envelope Encryption

We use a multi-tiered encryption strategy known as Envelope Encryption. This limits the exposure of any single key and allows for easier key rotation.

Threat Model

What happens if...

The Database is Leaked?

Impact: Low. Attacker gains access to:

• Encrypted Secrets (Ciphertext)
• Encrypted Data Keys
• User Metadata

They cannot decrypt any secrets because the Master Key is not in the database.

The Server is Compromised?

Impact: Critical. If an attacker gains full shell access to the running server, they can read the ENCRYPTION_KEY from the environment.

• Mitigation: Use a hardened infrastructure provider (e.g., Vercel, AWS ECS). Restrict access to the production environment. Envault does not store decrypted secrets on disk.

A Developer's Laptop is Stolen?

Impact: Medium.

• The attacker might have access to the local .env file if it was pulled.
• Mitigation: envault pull does not persist credentials permanently. Revoke the user's access immediately via the dashboard to prevent fetching new secrets.

Key Rotation

Envault supports key rotation to minimize the impact of a potential key compromise.

1. Generate New Key: Create a new 32-byte random string.
2. Update Environment: Update the ENCRYPTION_KEY variable on your deployment to the new key, and set the old key to OLD_ENCRYPTION_KEY.
3. Run Scavenger Process: Call the Supabase edge function to process the migration:

   curl -X POST 'https://<PROJECT_REF>.supabase.co/functions/v1/rotate-keys' \
     -H 'Authorization: Bearer <YOUR_SUPABASE_SERVICE_ROLE_KEY>'

   This function decrypts all Data Keys with the Old Master Key and re-encrypts them with the New Master Key.