Security — account & platform

Most modern factor: Touch ID / Face ID / Windows Hello / YubiKey. Phishing-resistant, no codes to type. The passkey is registered over WebAuthn with the relying party xictraq.com (algorithms ES256 and RS256, attestation “none”). Logging in with a passkey is single-step: a registered passkey signs you in directly, no prior password is required — the cryptographic signature replaces both factors in one step.

Every sign-in verifies challenge, RP ID hash and origin server-side — only https://xictraq.com and https://www.xictraq.com are accepted, a phishing domain never receives a valid assertion. In addition XICTRAQ watches the authenticator sign count: if the counter does not increase monotonically, the platform treats it as a sign of a cloned authenticator, rejects the sign-in and records the event in the audit log.

Alternative when passkeys are not available: scan QR code with authenticator app (Google Authenticator, Authy, 1Password, Bitwarden, Microsoft Authenticator) → 6-digit code at login. The implementation follows RFC 6238 (HMAC-SHA1, 30-second window, 160-bit secret) and accepts a tolerance of one slot in each direction (±30 seconds) when verifying, so a just-expired code does not fail immediately. We generate backup codes on activation — keep 8 of them safe in case your phone is lost.

We recommend passkeys for sensitive accounts (Agency plan, accounts with many websites) but never enforce a second factor — plain email logins remain fully usable. TOTP setup is two-stage: /auth/totp/setup first creates a pending secret with QR code, and only the first correctly entered code via /auth/totp/enable arms 2FA. Disabling requires password plus a valid code (or backup code), so a stolen login cookie cannot switch off the second factor.

When TOTP is active, login does not return a token directly but a short-lived challenge token valid for 10 minutes. Within that window at most 5 failed attempts are allowed; after that the challenge is discarded (response 429) and a fresh login is required — so a 6-digit code cannot be brute-forced across the open window. Every failed attempt is recorded as auth.login.2fa_failed in the audit log.

Minimum 10 characters — enforced equally on registration, change and reset. Passwords are hashed with bcrypt (cost factor 12) and a per-user salt; the plaintext is never stored. Changing via /auth/password requires confirming the current password first, after which all other sessions are revoked — the current session stays active.

The reset link is throttled to at most 3 requests per hour per email address, and the response is always generic (no hint whether the address exists — protection against account enumeration). The token sent is valid for 60 minutes and is itself stored only as a SHA-256 hash. A successful reset invalidates all existing sessions; if 2FA is active on the account, the reset does NOT log in directly but additionally demands the second factor — so an attacker with mere inbox access does not bypass 2FA.

When you change your password, all Sanctum tokens for the account are revoked — every other browser, device and app is logged out. The current session stays active. Personal access tokens (PATs for API access) are exempt — revoke them separately in /app/settings/api-keys so scripts don't break by accident.

You can be logged in on several devices at once with the same account. Under /app/settings/security, XICTRAQ lists your active sessions (up to 20, sorted by last use) — each with a device label, creation and last-use timestamp; the current session is marked as such. Any other session can be revoked individually, or you can use “Log out all others” to end every device except the current one. For safety you cannot remove the session you are currently using — use the global logout or a password change for that. Test and admin-impersonation tokens are deliberately hidden from this list: support access via impersonation runs as a separate admin session, appears only in the admin area and never shows up in your device overview.

In /app/settings/security you see every registered passkey with name, creation date and last use. Multiple passkeys can coexist (e.g. phone + hardware token); a second factor on the same device automatically gets a numbered default name you can override. Each one renameable or deletable — for a lost device, just remove it here; the others stay usable.

Detection is opt-in per website (watch toggle, from the Starter plan) and learns your target state (baseline) over the first 3 runs. A suspicion raises an event with severity “critical” via your alert channels; when the score drops, the event closes automatically. The full description of the three layers, the score logic and baseline learning is in the screenshots module.

While defacement detection watches your page as a whole, script integrity looks specifically at the content of each embedded third-party script. It complements two related hardening measures: Subresource Integrity (SRI) prevents loading of altered files in the browser, CSP reports surface policy violations from real visitor browsers — script integrity detects the unnoticed hash change itself, server-side.

By default the digest is generated from fixed rules (no token usage): it states the score with a grade, counts how many of the 6 headers are set and lists the missing ones to add. A richer AI narration is prepared on the platform side but currently not switched on and cannot be chosen per account; if it ran, the rule-based fallback would kick in automatically on failure. Either way only aggregated values are processed — score and header status, never domain, host or individual findings (privacy-friendly).

• Physical access: hosting in certified data centers within the EU; the assured physical protection measures are documented in the data center operator's TOM data sheet (named in the privacy policy). • System access: server administration via state-of-the-art authentication and authorisation mechanisms with protection against unauthorised access. • Data access: role and permission model (User → Team → Admin); strict tenant separation at database level; no system-level default sharing between accounts. • Segregation: logical separation of data sets by functional domain and between test and production systems. • Pseudonymisation: cookieless visitor capture via a daily identifier formed from the IP address and a random value (salt) generated anew each day and deleted once the day is over, so that no attribution to the IP address is possible afterwards; the IP address itself is not stored; passwords stored exclusively as hashes using an established procedure; API tokens persisted only as hash values.

• Transmission control: transport encryption according to the state of the art (HTTPS/TLS) for all interfaces; HSTS enabled. • Input control: security-relevant administrative actions are logged; retention is determined by necessity and the storage-limitation principle (Art. 5(1)(e) GDPR). • Script integrity: versioned tracker with Subresource Integrity hash (SHA-384) for detecting unauthorised modifications on customer websites.

• Backups: regular automated backups; retention and recoverability are ensured as part of our hosting setup. • High availability: distributed monitoring setup across multiple EU locations, so that the failure of one location does not impact the platform as a whole. • Overload protection: DDoS protection at network level by the data center operator; rate limiting at application level to protect against brute force and abuse. • Self-monitoring: live status of platform components at xictraq.com/status.

• Event-driven review of these measures before significant architecture or sub-processor changes and after security incidents. • Continuous monitoring of the open-source components used for known vulnerabilities through the package managers of our environment (npm/composer). • Customer information on personal data breaches within 72 hours pursuant to § 9a section 7 of these Terms.