Securing the Local Environment: Zero-Knowledge Secret Management for Teams

We’ve all seen it: a developer commits a .env file containing production Stripe keys, or drops database credentials into a private Slack channel because "the QA engineer needed it." Secret sprawl is one of the most common vectors for security breaches in modern software engineering.

When building Env Secret Lock, my goal was to solve the convenience-versus-security trade-off. I wanted a CLI tool that developers would actually use—allowing them to encrypt local environment files, commit the encrypted artifacts securely to Git, and synchronize keys across a team without a central authority having plain-text access.

Here is an architectural deep dive into how I built this secure, zero-knowledge locker in Node.js.

The Threat Model: Local Decryption, Zero Cloud Trust

A standard cloud-based secret manager holds the master keys. If the cloud vendor is compromised, your plain-text secrets are exposed.

To eliminate this vector, Env Secret Lock employs a Zero-Knowledge Architecture:

1. Master Password: The user provides a master password. This password never leaves their local machine.
2. Key Derivation (PBKDF2): We derive a highly secure encryption key locally using PBKDF2 with 100,000 iterations and a unique salt.
3. Symmetric Encryption (AES-256-GCM): The local .env is encrypted using the derived key.
4. Cloud Synchronization: Only the encrypted payload, the PBKDF2 salt, and the Initialization Vector (IV) are pushed to the team sync server. The server is completely blind; it cannot decrypt your secrets.

┌────────────────────────────────────────────────────────┐
│                   Local CLI Session                    │
│                                                        │
│  [ Master Password ] ──> [ PBKDF2 (100k + Salt) ]      │
│                                  │                     │
│                                  ▼                     │
│  [ Plain .env ] ─────────> [ AES-256-GCM ]             │
│                                  │                     │
└──────────────────────────────────┼─────────────────────┘
                                   │ Generates
                                   ▼
                   ┌──────────────────────────────┐
                   │ Encrypted Payload (.env.enc) │
                   │  + Salt, IV, Auth Tag        │
                   └───────────────┬──────────────┘
                                   │
                                   ▼ (Pushed to Github / Sync DB)
                    ┌────────────────────────────┐
                    │      Storage Backend       │
                    │   (Zero-Knowledge Cloud)   │
                    └────────────────────────────┘

Technical Implementation: Cryptography in Node.js

Node.js provides a robust native crypto module. When encrypting sensitive configurations, we cannot use weak algorithms or insecure modes like AES-256-ECB. We must use an authenticated encryption mode. I selected AES-256-GCM (Galois/Counter Mode) because it provides both confidentiality and authenticity (tamper protection).

Here is the exact encryption and decryption implementation used by the CLI core:

import crypto from 'crypto';

const ALGORITHM = 'aes-256-gcm';
const KEY_LENGTH = 32; // 256 bits
const IV_LENGTH = 12;  // 96 bits for GCM
const SALT_LENGTH = 16;
const ITERATIONS = 100000;
const DIGEST = 'sha512';

interface EncryptedPayload {
  encryptedData: string;
  iv: string;
  salt: string;
  authTag: string;
}

// Derive a strong cryptographic key from a human master password
function deriveKey(password: string, salt: Buffer): Promise<Buffer> {
  return new Promise((resolve, reject) => {
    crypto.pbkdf2(password, salt, ITERATIONS, KEY_LENGTH, DIGEST, (err, key) => {
      if (err) reject(err);
      else resolve(key);
    });
  });
}

// Encrypt plain-text string (the .env contents)
export async function encryptSecrets(plainText: string, masterPassword: string): Promise<EncryptedPayload> {
  const salt = crypto.randomBytes(SALT_LENGTH);
  const iv = crypto.randomBytes(IV_LENGTH);
  const key = await deriveKey(masterPassword, salt);

  const cipher = crypto.createCipheriv(ALGORITHM, key, iv);
  
  let encrypted = cipher.update(plainText, 'utf8', 'hex');
  encrypted += cipher.final('hex');
  
  const authTag = cipher.getAuthTag().toString('hex');

  return {
    encryptedData: encrypted,
    iv: iv.toString('hex'),
    salt: salt.toString('hex'),
    authTag: authTag
  };
}

// Decrypt ciphertext
export async function decryptSecrets(payload: EncryptedPayload, masterPassword: string): Promise<string> {
  const salt = Buffer.from(payload.salt, 'hex');
  const iv = Buffer.from(payload.iv, 'hex');
  const authTag = Buffer.from(payload.authTag, 'hex');
  const key = await deriveKey(masterPassword, salt);

  const decipher = crypto.createDecipheriv(ALGORITHM, key, iv);
  decipher.setAuthTag(authTag);

  let decrypted = decipher.update(payload.encryptedData, 'hex', 'utf8');
  decrypted += decipher.final('utf8');
  
  return decrypted;
}

Why AES-GCM Authentication Tags are Crucial

In standard cryptography, an attacker can modify parts of the encrypted file without decrypting it (a bit-flipping attack). If your .env contains:

DB_PORT=5432

An attacker might flip bits in the ciphertext. When you decrypt it, the database port might evaluate to 9999 or arbitrary strings, causing your app to fail or connect to an attacker-controlled proxy.

By using AES-GCM with cipher.getAuthTag(), Node.js creates a 16-byte authentication tag. When decrypting, decipher.setAuthTag() verifies the tag against the decrypted payload. If even a single bit of the file has been altered in Git or transit, deciphering throws an error immediately:

Unsupported state or unable to authenticate data

This ensures that developers are protected from malicious tampering.

Streamlining the CLI Integration

To make this frictionless for daily git operations, the CLI hooks into the local workflow.

Running env-lock pull automatically looks for the .env.enc file in the git repository, prompts the developer for the master password, decrypts it locally into .env, and updates .gitignore to ensure plain-text secrets are never committed accidentally.

Conclusion

Securing developer workflows requires making security easier than convenience workarounds. By utilizing zero-knowledge principles and production-ready AES-256-GCM encryption directly inside a Node.js CLI, Env Secret Lock allows engineering teams to keep their credentials out of Slack and Git history, completely risk-free.

If you are interested in exploring the CLI code, check out the Env Secret Lock repository details.