Where are EBS passwords actually stored?

Credential Types — Where Each Is Stored

Encryption Architecture

Every credential follows the same path from your browser to the database and back out at execution time. The plaintext password exists in memory only at two moments: when you type it into the UI, and when a command needs it.

Encryption Specification

Algorithm

AES-256-GCM — authenticated encryption with associated data (AEAD). GCM mode provides both confidentiality and integrity: if the ciphertext or IV is tampered with, decryption fails with an AuthTagMismatch error rather than silently returning garbage.

Key

256-bit (32-byte) key stored as a 64-hex-character string in the ENCRYPTION_KEY environment variable in Render's secret manager. The application crashes at startup if this variable is unset in production — there is no fallback to a hardcoded or derived key.

Per-row randomness

Each encrypt call generates a fresh 128-bit random IV via crypto.randomBytes(16). The IV, auth tag, and ciphertext are stored as separate columns. Re-encrypting the same plaintext produces a different ciphertext every time — no two rows are alike, so ciphertext comparison reveals nothing about plaintext equality.

-- Schema: ebs_credentials
id              UUID PRIMARY KEY
connection_id   UUID NOT NULL  ← FK to oracle_connections
credential_type TEXT           ← apps | system | sys | weblogic_admin | sysadmin_user | xml_gateway
username        TEXT           ← stored in plaintext (not sensitive)
encrypted_value TEXT           ← AES-256-GCM ciphertext (hex)
iv              TEXT           ← 128-bit random IV per row (hex)
auth_tag        TEXT           ← 128-bit GCM auth tag (hex)
rotated_at      TIMESTAMPTZ    ← last upsert timestamp
created_at      TIMESTAMPTZ    ← row creation

What Is NOT Stored

Audit Trail

Every decryption event is logged to the credential_access_log table before the plaintext is used. The log entry is written even if the command that follows fails — so the access is always recorded.

Key Rotation Procedure

When the ENCRYPTION_KEY needs to be rotated (e.g., suspected compromise, periodic compliance requirement), follow this procedure:

1. Generate a new key

   Run node -e "console.log(require('crypto').randomBytes(32).toString('hex'))" to produce a new 64-hex key. Store it securely — do not commit to any repo.
2. Re-encrypt all rows

   Decrypt every row with the old key and re-encrypt with the new key. Update the rotated_at column. This can be done in a maintenance window with a one-off script.
3. Update Render secret

   Set the new value of ENCRYPTION_KEY in Render's environment. The service will restart and pick up the new key. Old ciphertexts are invalid after this point — ensure re-encryption is complete first.
4. Verify decryption

   Run a POST to /api/connections/:id/credentials to re-store one credential and confirm it round-trips correctly after the restart.
5. Revoke old key

   Remove the old key from any intermediary storage. The old key no longer decrypts any live rows.

API Reference

All endpoints require a valid TuneVault session (cookie or Bearer token) and connection ownership.

-- Example: store an APPS password
POST /api/connections/abc123/credentials
Content-Type: application/json

{
  "credential_type": "apps",
  "username": "APPS",
  "value": "your_password_here"
}

-- Response (no plaintext ever returned)
{
  "credential_type": "apps",
  "username": "APPS",
  "rotated_at": "2026-05-18T10:45:00.000Z",
  "created_at": "2026-05-18T10:45:00.000Z"
}

SSH Authentication Model

Supported auth methods (Add Connection wizard)

Test SSH button — pre-save, no persistence

The Test SSH connection button in the Add Connection wizard fires POST /api/connections/test-ssh. The server opens a transient SSH session, runs a fixed allowlisted command (whoami && hostname && echo $ORACLE_SID && id), and returns the four output lines. The private key is transmitted over TLS, used in-memory, and never written to the database during the test — only after the user clicks Save.

SSH private key in ebs_credentials vault

The SSH private key is stored as credential_type = 'ssh_private_key' in the ebs_credentials table, using the same AES-256-GCM encryption and IV-per-row scheme as APPS / SYSTEM / WebLogic passwords. Every in-memory decryption event is appended to credential_access_log before the key is used. The plaintext key is never returned via any API endpoint.

Threat Model