Security at Time Travel

Authentication

• Passwords are hashed with argon2id, a memory-hard algorithm designed to resist offline cracking. We never store or transmit a readable password, and cannot tell you what yours is.
• Sessions use signed, httpOnly cookies that page JavaScript cannot read, marked Secure in production and SameSite=Lax to mitigate cross-site request forgery.
• Refresh tokens rotate on every use. Replaying a spent token is treated as a compromise and revokes the session rather than issuing new credentials.
• Repeated failed sign-in attempts lock the account temporarily to blunt credential-stuffing and brute-force attempts.
• Platform operators sign in through a separate, unlinked surface. A credential for one surface is rejected on the other by the server, not merely hidden in the interface.

Authorisation

• Access is governed by role-based permissions checked on the server for every request. The interface hides what you cannot do, but the server is what enforces it.
• Agency data is scoped to the organisation that owns it. One agency cannot read another’s bookings, travellers, wallet or documents.
• Significant actions — sign-ins, approvals, wallet movements, role changes, document downloads — are written to an audit log recording who acted, when, from which IP address and with what outcome.

Data protection

• All traffic is served over HTTPS with HSTS. The application sets a strict Content Security Policy and sends no data to third-party origins.
• Uploaded documents are validated by inspecting file contents rather than trusting the file extension, and are stored privately rather than on the public web.
• The wallet ledger is immutable: entries are appended, never edited, so the financial history can always be reconstructed and audited.

Platform integrity

• Rate limiting is applied across the API, with tighter limits on authentication and other sensitive endpoints.
• Requests carry a correlation identifier so an issue can be traced end to end without exposing user data in logs.
• The service refuses to start in production with development secrets, debug interfaces enabled, or an insecure configuration — a misconfigured deploy fails loudly instead of serving traffic.

What we are still working on

We would rather tell you what is not done than imply it is. Multi-factor authentication and single sign-on are in development and are not yet available. We publish this page and update it as that changes.

Reporting a vulnerability

If you believe you have found a security issue, email security@timetravel.com. Include enough detail to reproduce it, and give us reasonable time to investigate and fix before disclosing it publicly.

We will acknowledge your report, keep you informed while we work on it, and credit you if you would like us to. We will not pursue legal action against researchers who act in good faith, avoid privacy violations and data destruction, and do not degrade the service for others.

Please do not run automated scanning or load testing against production, and do not access, modify or exfiltrate data belonging to any agency or traveller.