Zero-Knowledge Encryption

An optional layer that places a user-held passphrase on top of standard protection. While locked, even an operator cannot decrypt your credentials.

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.

🔒 Guarantee: while a project is locked, no NeoSQL employee or administrator (even with admin console + code access + KMS privilege combined) can read its credentials in plaintext.

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

UserUser-onlysecret key (passphrase)Argon2id KDFKEK_user32-byte derived key(client memory only)wrapDEK (32 bytes)AES-256-GCM keyDB: stored KEK_user-wrappedRuntime: client memory onlySent per-request via headerencrypt15 _enc fieldshost · port · url · passwordSSL · SSH · proxy ...AES-256-GCM ciphertextRe-encrypted with new DEKNeoSQL server DB (nv_encryption_key + nv_connection)Only encrypted_dek_user and _enc are stored — secret key never savedOperatorAdmin console ❌Direct DB query ❌KMS access ❌Impossible without the secret key❌

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.

[Screenshot: LOCK button at top right of project page]
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.

[Screenshot: secret-key setup modal — generate or manual input]
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.

[Screenshot: secret-key display + download/copy + confirm checkboxes]
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.)

[Screenshot: unlock modal on project entry]

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.

Value (min)Behavior
0 (Off)Auto-lock disabled — stays unlocked until manually locked
1Auto-lock after 1 minute of inactivity
5Auto-lock after 5 minutes of inactivity
30Auto-lock after 30 minutes of inactivity
480Auto-lock after 8 hours of inactivity
[Screenshot: My Page → Security → auto-lock dropdown]

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.

[Screenshot: LOCK button dropdown menu]

Note: Auto-lock zero-fills the plaintext DEK in client memory. No lock state is stored on the server, so other devices are unaffected.

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

⚠️ The secret key itself cannot be recovered. This is not a defect — it is the essence of Zero-Knowledge. NeoSQL operators cannot help because they never held the key.
💡 What's NOT lost: only the encrypted credential fields stored in NeoSQL's DB (DB password, SSH key, SSL cert, etc.) become unreadable. Your actual database data is untouched, and the credentials themselves still exist with whoever originally issued them — your DBA, infrastructure team, password vault, or 1Password share. Ask them to re-share the connection details and you can rebuild the project in minutes.

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.