Security model overview

NeoSQL's security goal is "even operators cannot see your data."

Standard protection — applied to every project automatically

The moment you create a project, NeoSQL encrypts the following 15 credential fields with AES-256-GCM.

15 encrypted fields

• Connection-level (shared by project members): host · port · URL · database · DB user · DB password · SSL client cert · SSL client key · SSL client key password
• User-level (per member): SSH username · SSH password · SSH private key · SSH passphrase · proxy username · proxy password

AWS KMS Envelope Encryption

A unique DEK (Data Encryption Key) is issued per project and the DEK itself is wrapped by AWS KMS Customer Master Key. Even if the entire server database is leaked, no credential can be decrypted without the KMS key.

Plaintext credentials never appear in the UI

Connection lists, project screens, and ERDs never display passwords or certificates in plaintext. Only the edit modal handles them as masked input.

Standard protection — encryption flow

User → KMS-DEK → AES-256-GCM → 15 fields. KMS CMK seals the DEK so even an operator without KMS access cannot reach credentials.

NeoSQL administrator access policy

The administrator console (CMS) shows operational data only — user ID, email, subscription status. It NEVER displays user DB credentials on any screen.

Under standard mode, an operator with both code access and KMS access could in theory decrypt credentials by querying the database directly through the KMS API. Zero-Knowledge mode closes this last gap by removing the operator's ability entirely.

Zero-Knowledge mode (optional)

Zero-Knowledge adds a layer that only the user can unlock — a passphrase known only to you. NeoSQL servers never store this passphrase, and no operator privilege can decrypt without it.

How it works

• The secret key is handled only on the client (Electron or browser); the plaintext passphrase is never sent to the server.
• Argon2id KDF derives a 32-byte KEK_user from the passphrase, which then wraps the DEK once more before storage.
• On unlock, the client recreates KEK_user from the passphrase, unwraps the DEK, and keeps the plaintext DEK only in client memory (browser/Electron Pinia store). Every API call to the project carries the DEK in a single HTTP header (X-Neosql-Zk-Dek); the server uses it to decrypt for that one request and immediately zero-fills it — no long-lived server-side DEK cache exists.
• Because the plaintext DEK lives only in the memory of one client (browser tab or Electron process), the same user must unlock on each device — desktop, web, another PC.

Zero-Knowledge — encryption flow

User secret key → Argon2id → KEK_user → wraps DEK on top of KMS. The plaintext DEK lives only in client memory at runtime and is sent to the server per-request via X-Neosql-Zk-Dek header (no server-side cache). Without the secret key, KEK_user cannot be regenerated, and without KEK_user, the DEK cannot be unwrapped.

Getting started with Zero-Knowledge

Activate it via the "Secret Key Lock" button in the project. Empty projects get a fresh key; projects that already have credentials are automatically re-encrypted with a new DEK so the old KMS DEK becomes useless.

1

1. Click "Secret Key Lock" in the project toolbar

Only the project owner can click. Members see it disabled.

2

2. Generate or enter a secret key

Recommended: auto-generate 32 chars. Or enter 12+ chars manually. Korean / emoji / symbols all allowed. A strength meter blocks weak keys.

3

3. Back up the key (most important)

The key is shown ONCE. Save it in 1Password or similar. Download .txt or copy to clipboard. Two confirmation checkboxes ("Recovery is impossible if lost") must be ticked.

4

4. Auto-unlock + start working

The session is auto-unlocked right after setup. For projects with existing connections, all 15 fields are re-encrypted with the new DEK so any old key an operator might hold is invalidated.

Unlock and auto-lock

Future entries require the secret key. Desktop users can check "Save securely on this computer" to store it in the OS keychain, enabling auto-unlock on that device. (Browsers cannot access the OS keychain directly.)

Auto-lock duration

From My Page → Security, choose your inactivity timeout (1m / 5m / 30m / 8h / off). After timeout, the client zero-fills its in-memory plaintext DEK and the next action requires the key again.

Lock / Change / Disable menu

From the LOCK button dropdown: "Lock session now", "Change secret key", "Disable secret-key lock (permanent)". All require project owner permission.

Team collaboration — sharing the secret key

Because NeoSQL never stores the secret key, you must share it through external channels (1Password shared item, internal vault, Slack DM, etc.). NeoSQL does not facilitate this transmission — that is exactly what makes the "operator-blind" guarantee possible.

Each member enters the key once on their device, optionally checking "Save securely on this computer" on Desktop for future auto-unlock.

After a key change, other members' saved keys are auto-invalidated; the next entry shows "Cannot unlock with the saved secret key." Re-share the new key out of band.

If you lose the secret key

Practical recovery flow

• ① Obtain the DB connection info again from its source (DBA / vault / teammate).
• ② Create a new project, or disable Zero-Knowledge on the existing project to clear the unrecoverable encrypted fields and then re-enable it with a new key.
• ③ Re-enter the credentials.

Metadata such as ERD and SQL Editor content can be migrated separately with a dedicated migration tool.

If this trade-off is unacceptable, stay on standard mode. There, NeoSQL operators can (in theory) assist with recovery.

Limits — honest disclosure

• While a project is unlocked, the plaintext DEK is held only in the client (browser/Electron). It travels to the server on each request via the X-Neosql-Zk-Dek header, lives in JVM memory only for the duration of that single request, and is zero-filled immediately. A determined operator with RAM-dump capability could in theory snapshot the JVM during a single request, but there is no long-lived server-side DEK cache to target.
• Browsers cannot access the OS keychain directly, so you must enter the secret key on every entry. Desktop apps offer the auto-unlock option.