Security & Privacy

DarkForce is built server-side-first: authorization, source-stripping, scoping, and rate limits are enforced on the server, never in the browser. This page documents the accepted risks honestly.

Accepted risk: record hash is a credential-confirmation oracle (D-98)

Every record is addressed publicly by a SHA-1 hash of its normalized identity. Because that same hash can confirm whether a credential exists, the public hash is a credential-confirmation oracle. This is an inherited, accepted risk (recorded in the ADRs); the mitigation is that the hash is one-way and normalized, and access to the full record data still requires an authenticated, scoped session or token. We document it here rather than obscure it.

Accepted risk: store-all data stance (D-95)

DarkForce retains collected breach data (including non-customer data) so that records are linkable to a customer's monitored domains the moment a match appears. This "store-all" stance is an accepted risk: it improves detection coverage at the cost of holding data that is not strictly tied to a paying customer. The retention policy and partition rotation are documented in the runbooks.

Accepted risk: credentials stored plaintext at rest (D-109)

Leaked credentials (records.password) and source/connector credentials (sources.credentials) are stored in plaintext, not hashed or encrypted at rest. This is the product's core accepted risk: the service exists to surface the leaked plaintext so customers can act on it, and hashing at rest would defeat that purpose. Masking in the UI is presentation-only (P07) — the server remains the authority for who may reveal a value (L16), and every reveal/export is audited. Connector credentials are write-only (L18): they are accepted plaintext but never returned in any response or log.

How we protect data