Credentials

The credentials Loomscope stores on your behalf — SNMP community strings and v3 users, cloud access keys, integration tokens — live in one table, encrypted at rest with AEAD keyed by LOOMSCOPE_KMS_KEY.

Manage them under Settings → Credentials.

Kinds

SNMP v3 with authentication and privacy is the one to use wherever the devices allow it. v1 and v2c send the community string in cleartext, and Loomscope encrypting it at rest does nothing about that.

How they are protected

Encrypted at rest with AEAD, using pgcrypto, keyed by LOOMSCOPE_KMS_KEY which lives only in the environment. The database alone does not decrypt them.

Never logged. A redacting logger drops credential fields, community strings, API keys and session tokens before they reach a log line.

Scoped to the organisation like every other row, behind row-level security with FORCE.

Never returned to the browser. A credential is written once and read only by the process that uses it. The UI shows metadata — name, kind, when it was last used — not the value.

Where they are used from

This distinction matters more than it looks:

• SNMP credentials are sent to daemons, because the daemon is what talks SNMP. They reach it over the authenticated channel, for the specific job it is running.
• Cloud credentials never leave the control plane. Cloud discovery runs there by design, so a daemon host holds no cloud credentials — a compromised scanner gets an attacker a scanner, not your AWS account.

LOOMSCOPE_KMS_KEY

Everything on this page depends on one environment variable.

Losing it makes every stored credential permanently unreadable. Leaking it means treating all of them as compromised. It belongs in a secret manager, with a copy somewhere that is not the server.

Generate it once:

openssl rand -base64 32

The failure mode worth knowing about

A database restored under a different key comes back looking completely healthy. Hosts, users, networks, findings — all present. And every stored SNMP community, cloud key and integration token silently fails to decrypt. You find out days later, when scans stop authenticating and cloud sync stops returning anything.

That is why the backup archive records a one-way fingerprint of the key that encrypted the data, and why restore.sh refuses to proceed when the key you hold is not that key. See Backup and restore.

Rotating it

There is no built-in rotation. Rotating means decrypting under the old key and re-encrypting under the new one, which requires both keys at once — so plan it as a maintenance operation:

1. Take a backup and verify it restores.
2. Re-enter every credential under the new key, or script the re-encryption against the database with both keys available.
3. Confirm each credential still works before discarding the old key.

If the credentials are genuinely expendable, deleting and re-entering them by hand is the simpler path.

Testing a credential

Every credential has a Test button that exercises it the way the real thing does — an SNMP get against a device, a cloud API call, a delivery through the notification pipeline. A test that takes a different path than production is a test that proves less than it appears to.