Protect stored credentials

Protect stored credentials#

Querona stores the credentials of the data sources it connects to in its metabase, encrypted with a key derived from the shared secret held in the instance configuration file (%PROGRAMDATA%\Querona\conf\instance.config). The strength of that secret therefore bounds the protection of every stored credential: anyone who can read both the metabase rows and the secret can recover the credentials in clear text.

The same file also holds the connection string Querona uses to reach its own metabase, which may itself contain a password. Treat the file as a secret: restrict its permissions to the Querona service account and local administrators.

The startup check#

Each time the Querona Service starts, it inspects the instance configuration and writes a warning to the log for each weakness it finds. The service always starts — these are advisory diagnostics, not errors.

Reported condition

Meaning

Shipped default secret

The shared secret is still the value delivered by the installer. It is identical on every installation that has never changed it, so it provides no real protection.

Missing secret

No shared secret is configured at all.

Below strength floor

The secret is customized but shorter than 16 characters, or repeats too few distinct characters to resist an offline guessing attack.

Metabase connection not encrypted

Traffic to the metabase — including stored credential ciphertext — crosses the network in clear text.

Metabase server certificate not validated

The connection is encrypted but accepts any server certificate, which defeats encryption against an active attacker positioned between Querona and the metabase.

Metabase password stored in configuration

The metabase connection authenticates with a password kept in the configuration file rather than with an integrated Windows identity.

Metabase connection could not be inspected

The connection string carries a keyword or a value the database client does not accept, so nothing is known about its security either way. This is not a statement that it is sound.

Warning

Do not change the shared secret on its own. Every stored data source credential is encrypted with a key derived from it, so replacing the value makes those credentials unreadable and the affected connections stop working. Rotate the secret only as part of a planned maintenance window in which you also re-enter every data source credential.

On a multi-node installation the same value also authenticates the connections between nodes, so change it on every node in that same window - a node left with the old value can no longer join the others.

Harden the metabase connection#

Edit the MetadataConnectionString property in the instance configuration file, then restart the Querona Service.

  1. Prefer an integrated Windows identity over a password. Use Integrated Security=True and grant the Querona service account access to the metabase, instead of User ID and Password.

  2. Require encryption with Encrypt=True, once the metabase server presents a certificate the Querona host trusts.

  3. Leave TrustServerCertificate unset so the server certificate is validated. If the certificate name does not match the server name you connect to, set HostNameInCertificate to the expected name rather than disabling validation.

Security settings on data source connections#

A SQL Server data source has dedicated settings for encryption, certificate trust and credentials. These settings are the only supported way to configure them.

The free-form additional parameters of a SQL Server connection are appended to the connection string after those settings, and the client honours the last occurrence of a repeated keyword. A security keyword placed there would therefore silently decide the connection’s real behaviour while the connection’s own settings still described something else.

Querona refuses such a connection and names the offending settings, so the stored configuration and the connection’s actual behaviour cannot disagree.

A keyword is refused when the connection has a setting of its own for it, because only such a keyword can contradict what the configuration shows:

  • Encrypt

  • TrustServerCertificate

  • HostNameInCertificate

  • ServerCertificate

  • Integrated Security (and Trusted_Connection)

  • User ID (and uid, user)

  • Password (and pwd)

  • Initial Catalog (and Database)

A keyword is also refused when it changes where the connection’s credentials are sent or who can read them back, even though the connection has no setting that could say so:

  • Data Source (and Server, Address, Addr, Network Address) - it would send the configured credentials to a server the stored settings do not name

  • Failover Partner - it names the mirroring partner Querona falls back to when the primary server is unreachable, and that fallback carries the same credentials to a server the stored settings do not name

  • Persist Security Info - it makes the password readable back off an opened connection

A keyword that only selects or enables a mode is not refused: it weakens nothing, moves no credential and exposes none. Authentication is the case that matters in practice - a Microsoft Entra authentication mode is reachable only through the additional parameters, so it stays available there.

If an existing connection fails with this message, remove the named keywords from its additional parameters and set the corresponding connection settings instead. Additional parameters that carry no security keyword are unaffected.

Querona also writes a log warning, once per data source, when a connection ends up without encryption or without certificate validation. The connection is still made — the warning records that its traffic is not fully protected.