Security and Multi-user Server

This chapter collects what OmniDB does to protect saved credentials and a shared, multi-user server, and what that means for you as an administrator or user. For installing and exposing the server see Deploying omnidb-server; for command-line password management see OmniDB Config Tool.

“Server mode” below means omnidb-server started without -A — a multi-user instance people sign in to from a browser, whether it listens on loopback only or on a network address (-H). The desktop app is always single-user.

Saved passwords are encrypted

Database passwords saved in a connection, SSH passwords/passphrases and SSH private keys are encrypted (AES-256-GCM) before they are written to OmniDB's user database, omnidb.db. The encryption key is not stored in that file: it is kept in the operating system's secret store — the macOS Keychain, the Windows Credential Manager or the Linux Secret Service — so a copy of omnidb.db alone does not reveal them.

Where no secret store is reachable (typically a headless Linux server), OmniDB keeps the key in a file named .connection_secret_key (readable by its owner only) in the OmniDB home directory instead; once that file exists it is always used. In that case:

back the key file up together with omnidb.db, and protect both equally;
if the key is lost, the stored secrets cannot be recovered — the connections still exist, but their passwords and SSH keys have to be entered again.

Existing unencrypted entries from older versions are encrypted automatically the first time a newer version starts. If you would rather not store a password at all, leave it empty in the connection form: OmniDB then asks for it when needed and keeps it only in memory, for 30 minutes, for your session (see Creating Users and Connections).

The initial `admin` account

A new server-mode installation creates one superuser, admin, with a random password that is printed once to the server's log output:

omnidb-server: initialized a new app database — initial login: admin / <password> (shown only once; change it under Settings, or run: omnidb-server --set-password admin)

Sign in with it and change it under Settings > Password, or set a password of your choice beforehand from the command line:

omnidb-server --set-password admin [-d /path/to/homedir]

The desktop app never shows a sign-in page; it signs in to its own local, loopback-only server automatically.

Sign-in protection and sessions

After 10 failed sign-in attempts for the same user name, or from the same client address, within 15 minutes, further attempts are refused with Too many failed sign-in attempts. Please try again in 15 minutes. The counters are kept in memory and reset when the server restarts. Behind a reverse proxy the client address is the proxy's address.
Deleting a user ends all of that user's sessions immediately, and removing superuser status takes effect immediately. Changing a password (in Settings or with --set-password) applies to new sign-ins at once; a password changed in Settings also signs out that user's other sessions.

Restrictions in server mode

Because every connection of a multi-user server is opened by the server process, on the server machine, some connection options that would read the server's own files are restricted:

SQLite connections (a SQLite database is a file on the server) can only be created and used by OmniDB superusers. They cannot point inside OmniDB's own home directory, and file: URIs are rejected.
PostgreSQL connection strings may not use the parameters passfile, servicefile, service, sslkey, sslcert, sslrootcert, sslcrl or sslcrldir.

These restrictions do not apply to the desktop app, where the files are your own.

Public connections

A connection marked Public connection? can be used by every OmniDB user on the server, but only its owner can edit it. For everyone else:

the saved password is never sent to their browser, and a password embedded in the connection string is shown masked;
Test Connection always tests the stored server, port and database — changing those fields in the form first does not redirect the stored password somewhere else.

Exported files

Query exports and DBML exports are written to the server's temp folder under random names and can only be downloaded by the user who created them. They are deleted automatically after 24 hours.

SSH host keys

SSH tunnels and SSH terminal connections verify the server's host key against the ~/.ssh/known_hosts file of the operating-system user running omnidb-server. An unknown or changed host key is refused — OmniDB does not silently trust a host on first use. Add the host once from that account, for example:

ssh [email protected]        # accept the key once
# or
ssh-keyscan ssh-server.example.com >> ~/.ssh/known_hosts

Network exposure

There is no built-in TLS. Keep omnidb-server on 127.0.0.1 (the default) behind a TLS-terminating reverse proxy rather than exposing plain HTTP with -H 0.0.0.0 — see Deploying omnidb-server. While bound to loopback, the server only answers requests addressed to 127.0.0.1, localhost or [::1] with its own port, which protects it against DNS-rebinding attacks from web pages. Session cookies are marked Secure when the request arrives over TLS or with X-Forwarded-Proto: https, and all state-changing requests are protected against cross-site request forgery.