Argon2id hashing
Passwords are hashed with Argon2id: memory-hard and GPU-resistant.
Home / Security
Enterprise-grade security, built in
A security product has to be secure itself. ThreatLark ships with a hardened authentication stack, tamper-evident auditing and encryption at rest, in front of every tool.
Authentication
Strong identity, layered
Password, second factor and SSO options, with brute-force defenses on every path.
TOTP multi-factor
Authenticator-app codes (Microsoft/Google Authenticator, Authy). The first-run admin must replace the temporary password and enroll MFA before doing anything else.
WebAuthn passkeys
Hardware and platform authenticators can be added as a second factor from Account Settings.
Microsoft SSO
Optional OIDC sign-in with Microsoft Entra ID. It is invite-only: only users an admin has explicitly enabled for SSO can sign in, and the admin account never uses SSO.
Brute-force defense
Per-account lockout after repeated failures (defaults: 5 attempts, 15 minutes) plus automatic per-IP blocking across usernames. All thresholds are live-tunable.
Session policy
Server-side sessions with idle and absolute expiry, a concurrent-session limit, session regeneration on login and one-click admin revocation.
Access control
Least privilege, enforced where it counts
Authorization is enforced on the server, not just in the UI.
Role-based access control
Two roles, ADMIN and USER, plus a per-tool permission for every user and scanner:
full | Can launch scans and view results |
read-only | Can see the tool and past results, but not launch scans |
none | Hidden from navigation and blocked at the API |
Permissions are enforced at the API layer, not just in the UI, so a restricted user cannot reach a blocked tool by calling the API directly.
Data scoping
- Scan history, findings and reports are scoped to their owner
- Cross-user visibility is an explicit opt-in through target-group sharing
- Admins can inspect and manage users, sessions, blocked IPs and settings
- Admin accounts always keep password login, with MFA and passkeys
Data protection
Encrypted at rest
Defense in depth for everything the platform stores.
Encrypted database
The whole database is an encrypted libSQL file. A stolen disk image, copied file or misplaced backup exposes nothing without the key.
Secrets at rest
MFA secrets, integration API keys and remote-backup credentials are encrypted with AES-256-GCM, and the key can be rotated from the admin panel.
Encrypted backups
Backups are wrapped in a second AES-256-GCM layer and can be pushed to SSH/SFTP targets on a schedule.
Database encryption protects a powered-off or copied database file. It does not protect a running process (which necessarily holds the key) or a compromised root account, so keep the key in a password manager or secrets vault.
Audit & integrity
A tamper-evident record of everything
Know who did what, and prove the record has not been altered.
- Every sensitive action (logins, MFA events, scans executed with targets and finding counts, group changes, password changes) is written to the audit log
- Each row is linked to the previous by hash, forming a chain; a Verify chain action proves nothing was altered
- The audit log is deliberately excluded from data-retention pruning, because deleting old rows would break the chain
- Filter by user or event type and export to CSV
Additional protections
- CSRF protection on every state-changing request (signed double-submit token)
httpOnly,Secure,SameSitesession cookies; production refuses to start without secure cookies- Per-route rate limiting
- Optional alerts to Slack, webhook or email for critical findings and account-security events
Safe by design
Scanning that respects your environment
The tools are active, so safeguards are part of the design.
Authorization attestation
Attack-surface and OT/IoT scans require an explicit acknowledgement that you are authorized to test the target scope.
Read-only probing
OT/IoT protocol checks send a single safe handshake, never a write, start, stop, program or login. Data-altering and DoS scripts are excluded, and nuclei skips DoS/intrusive templates.
SSRF protection
Web-facing tools resolve and validate targets first, rejecting private, loopback, link-local and cloud-metadata ranges, with DNS pinned against rebinding. Internal scanners allow private ranges deliberately.
Authorized use only. Every tool in ThreatLark can actively probe a target. Use it only against systems you own or have explicit, documented authorization to test. All access is logged and audited.
Questions about the security model?
Request a walkthrough and we will cover authentication, access control, data handling and audit in detail.