Security

DarkSint holds real, working credentials. These are the controls around them, and an equally plain account of what we have not earned the right to claim.

Last updated 9 October 2026 · DarkSint

Masked by default

The most important control is architectural, not cryptographic: nothing is revealed until someone deliberately reveals it. Every search returns redacted identifiers, no passwords, and truncated URLs.

The upstream source tracks unlock state per account, not per user. DarkSint re-masks on top of that, so a record another customer has revealed still arrives masked to you. What you reveal is visible to you alone.

Accounts and sessions

  • Passwords are hashed with Argon2id, the memory-hard algorithm, tuned well above defaults, and rehashed automatically when those parameters are raised.
  • Access tokens are short-lived (15 minutes) and signed; issuer and required claims are verified on every request, not just the signature.
  • Refresh tokens rotate on every use. If an old one is ever replayed (the signature of a stolen token), the entire session family is revoked immediately and every device is signed out.
  • The refresh token lives in an HttpOnly, SameSite=strict cookie scoped to the auth path, and is never readable by JavaScript. The access token is held in memory only, never in localStorage.
  • Two-factor authentication is available on every account, with the TOTP secret encrypted at rest.
  • Failed sign-ins and failed two-factor attempts are counted and locked out, so passwords cannot be ground down.
  • API keys are stored only as hashes and can be revoked individually; sessions can be revoked one at a time or all at once.

Encryption

Revealed credentials and two-factor secrets are encrypted with AES-256-GCM before they reach the database, so a database copy alone does not yield a single usable password. Traffic is served over TLS in production.

Being precise about scope: we encrypt these fields specifically. Whole-disk encryption underneath depends on the hosting provider, and we would rather state that than let the word “encrypted” do more work than it has earned.

Access and accountability

  • Every plan feature and quota is enforced on the server. The interface hides what you cannot do; the API refuses it.
  • Every search is recorded against the account that ran it (type, subject, time, outcome), which is both your history and our abuse-detection record.
  • Significant actions are written to an audit log with IP address, user agent and request ID.
  • Logs are scrubbed of personal data before they are written, so an operator reading them does not incidentally read credentials.
  • Rate limits apply per plan and per minute, and the shared upstream source sits behind a concurrency limit and a circuit breaker so one user cannot exhaust it for everyone.

Application hardening

  • Standard security headers on every response: no MIME sniffing, framing denied, no referrer leakage, and no-store caching so sensitive responses do not linger in a proxy.
  • Database access goes through a parameterised query layer; there is no string-built SQL.
  • Input is validated against strict schemas that reject unexpected fields outright rather than ignoring them.
  • The application container runs as an unprivileged user with no build tooling in the image.
  • Dependencies are pinned and the codebase is type-checked and linted in full on every change.

What we do not claim

Security pages are usually a list of reassurances. Here is the other half, because you are trusting us with real credentials and deserve to know where the line is today:

  • We are not SOC 2 or ISO 27001 certified, and we will not imply it with a badge.
  • We have not yet commissioned an independent penetration test. When we do, we will say so here and date it.
  • We do not offer a contractual uptime guarantee.
  • We do not run a paid bug bounty, but we do take reports seriously, see below.
  • No system is impossible to breach. Ours is designed so that a breach yields as little usable data as possible, not so that we can promise one will never happen.

Reporting a vulnerability

Send it to support@darksint.com. Tell us what you found and how to reproduce it; a proof of concept helps, and so does telling us how you would fix it.

We will acknowledge within 3 working days and keep you updated until it is resolved. We will not take legal action against anyone who reports a genuine issue in good faith, stays within their own test account, avoids other users' data, and gives us reasonable time before disclosing publicly.

If you find data that is not yours, stop, and tell us what you saw rather than how much you could see.

Contact

General: support@darksint.com · Privacy: support@darksint.com · Abuse: support@darksint.com

See also Terms, Privacy, Refunds, Responsible use and Security.