Security: how DIN protects the record

DIN runs on your machine and keeps the record there. This page says what protects it, what you are trusted to keep safe, and how to report a problem. What leaves your machine is on Your data.

The download is signed

Every release's SHA256SUMS is signed with minisign. The one-line installers (get.sh) check that signature against a key written into them before they install anything; with no way to check it, they install nothing and say SIGNATURE NOT CHECKED, so nothing was installed. From 1.0.39 the signed comment also names the release and its date, and the one-line installers refuse a signed release older than the one they expect, so an old release cannot be replayed. If you download the archive yourself, check the signature by hand before you run its install.sh: the key and the check are on Install.

The field answers to this machine only

The field listens on loopback (127.0.0.1), and from 1.0.39 refuses to bind anything else: FIELD_BIND must be a loopback address.
From 1.0.39 it also refuses (403) any request addressed to a name other than 127.0.0.1, localhost or [::1], which stops a web page from reaching it through DNS rebinding.
Every request needs the field token. The installer mints a long random one into ~/din/.din/field.token, readable only by you. From 1.0.39 the field refuses to start with a token under 16 characters, or one with surrounding spaces or control characters.
din and the plugin never send the token to a field on another machine unless you set DIN_ALLOW_REMOTE_FIELD=1. The field speaks plain http, so a teammate reaches it over an SSH tunnel: see Use DIN as a team.

Keep the field token private. Whoever holds it can read and stamp the whole field. No DIN program prints it.

The licence cannot be edited into a bigger one

A paid entitlement is signed (Ed25519) by our licensing service, and the field, the console, the plugin and din license each check that signature themselves. An entitlement that is unsigned, edited, expired or signed by another key reads as Free. From 1.0.39 an entitlement names the install it was issued to, so one copied to another machine reads as Free there.

Secrets in what is captured

Capture runs the personal-content filter, and the record store redacts credentials (API keys, tokens, passwords, private keys, connection strings and many provider formats) before a record is written.
The security facet notes what kind of secret was seen and where, never its value. Password-class findings are fingerprinted with a per-install key.
dinctrl-store security-scan checks a store you already have; --write redacts what it finds. See Your data.

Re-grades are only from this release's programs (from 1.0.39)

A re-grade replaces a stored record only when it was made by one of the three producers, din-record, din-session-record or din-import, whose sha256 is on the allow-list producer-allow.txt. Every release from 1.0.39 ships that file beside its programs and lists it in its signed checksums, and dinctrl.com serves it at /download/producer-allow.txt, beside SHA256SUMS. The 1.0.38 download has no such file. With no list, every replacement is refused and the store is untouched.

Reporting a vulnerability

Write to support@dinctrl.com with "Security" in the subject, as security.txt says. Include the release (din --version), the platform, the steps to reproduce and what an attacker would gain, and please give us the chance to ship a fix before you publish. Never send a field token, an API key or a whole licence key.