Credentials and secrets

You are about to hand a desktop application the credentials to a production database. You are entitled to know exactly where they go. This page says so, per platform, with the key names you can look up yourself.

The rule

Connection profiles keep only non-secret metadata in settings.json. The complete MongoDB connection string, the MongoDB password, the SSH password and the SSH private key passphrase are runtime-only values held in your operating system's credential store.

There is no plaintext-file fallback. If the platform credential store cannot be reached, saving fails or degrades to memory — it never quietly writes the secret to disk somewhere else.

Value	Where it lives
Profile name, colour, write protection	`settings.json`
SSH host, port, username, auth method, key path	`settings.json`
Accepted SSH host key fingerprints	`settings.json` — a digest of the server's public key, which is not a secret
Complete MongoDB connection string	OS credential store
MongoDB password	OS credential store, folded into the connection string
SSH password	OS credential store
SSH private key passphrase	OS credential store
SSH private key file	Wherever you keep it. TableCore reads it, never copies it

The keys, so you can check

Every entry is named after the profile it belongs to:

TableCore/connection/<profile-id>/mongodb-connection-string
TableCore/connection/<profile-id>/ssh-password
TableCore/connection/<profile-id>/ssh-private-key-passphrase

<profile-id> is the profile's id from settings.json, so you can match an entry in your keychain to a connection in the explorer without guessing.

Per platform

Windows

Entries go to Windows Credential Manager as generic credentials, written through CredWrite. Look under Control Panel → Credential Manager → Windows Credentials; the target name is TableCore/connection/… and the user name is TableCore.

macOS

Entries go to the login keychain as generic passwords, through the system security tool. The account is TableCore and the service is the key above. You will see them in Keychain Access. The password is passed to security on standard input rather than as an argument, so it never appears in the process command line where any user on the machine could read it.

Linux

Entries go to the Secret Service through secret-tool — that is GNOME Keyring, KWallet's Secret Service interface, or any other implementation. They are stored with attributes service=TableCore, account=TableCore and key=<the key above>, labelled TableCore credential, and seahorse or secret-tool lookup will show them.

secret-tool lookup service TableCore account TableCore \
  key connection/<profile-id>/mongodb-connection-string

A machine with no keyring falls back to memory, and says so

Linux without libsecret and a running keyring — a container, a headless session — has no credential store. Rather than refusing to add a connection at all, TableCore keeps the secret in memory for the life of the process and tells you: "This machine has no working credential store, so the connection details are kept in memory only and will have to be entered again after a restart."

It does not write a file it could read back unaided. That would be plaintext persistence under a different name. What you lose is persistence, and you are told before you save, not after the restart.

TableCore probes the store by writing and immediately deleting a throwaway entry the first time it needs to know, so the warning arrives before you type a password rather than after you discover it did not survive.

What happens on delete and uninstall

Deleting a connection profile removes its entries from the credential store. That is the only action that does.

Uninstalling TableCore does not. Uninstallers do not get to reach into your keychain, and one that did would be worse. If you are decommissioning a machine or handing it on, delete the profiles from inside the application first, or remove the TableCore/… entries from your keychain by hand.

%LOCALAPPDATA%\TableCore also survives an uninstall, which is what makes a reinstall keep your workspace. It contains no secrets.

Secrets in errors, logs and diagnostics

Driver errors carry connection strings in them, and connection strings carry passwords. Every diagnostic TableCore shows or writes goes through a redactor first, so a copied error detail or an application log is safe to attach to a bug report.

That redaction covers passwords, cookies, private keys and connection strings. It is not a licence to be careless with a screenshot of your explorer: the profile names are yours, and a host name in a tooltip is still a host name.

What TableCore never does

It never sends your connection string, your queries or your data to a service we run. The desktop application talks to your MongoDB server and, if you sign in, to the account service — and the account service never sees a database credential.
It never stores your Google, GitHub or Microsoft password. TableCore accounts are passwordless, and provider access tokens are used once and not persisted. See Accounts and sign-in.
It never migrates a connection string saved in the deprecated application's old format. Reading a legacy plaintext secret to carry it forward is a path that was deliberately not built.

Credentials and secrets

#The rule

#The keys, so you can check

#Per platform

#Windows

#macOS

#Linux

#What happens on delete and uninstall

#Secrets in errors, logs and diagnostics

#What TableCore never does