Security
Security at Arkive is architectural, not aspirational. This page describes how we handle encryption, data flows, authentication, and infrastructure.
Principles
Server-blind by default
Where possible, the server handles ciphertext only. Encryption keys are derived and held client-side. A server breach does not expose user content.
No ambient authority
Every action requires explicit authorisation. There are no implicit permissions, no shared admin credentials, and no privilege escalation paths by design.
Auditable state transitions
Subscriptions, entitlements, and access changes are driven by explicit state machines. Every transition is logged. No silent mutations.
Minimal data retention
We store what is necessary for the service to function. Stripe webhook payloads are stored with PII stripped. We do not build user profiles or behavioural models.
Encryption
Journal entries are encrypted client-side before storage. A Key Encryption Key (KEK) is derived from the user's recovery key using PBKDF2-SHA256 with 600,000 iterations. A random AES-GCM-256 Data Encryption Key (DEK) is generated client-side, wrapped with AES-KW using the KEK, and only the wrapped (encrypted) DEK is sent to the server. Raw keys are never transmitted.
Keys are not recoverable by Arkive. If a user loses their recovery key, their encrypted data cannot be decrypted. There is no password reset, no admin override, and no backdoor. This is by design.
All client-server communication uses TLS 1.2+ in transit. Data at rest on the server is encrypted at the storage layer, but this is secondary to the client-side encryption which provides the primary confidentiality guarantee.
Authentication
Arkive does not store passwords. Authentication is delegated to established identity providers (Google and Microsoft) via OAuth 2.0 / OpenID Connect.
Session tokens are short-lived JWTs. Token refresh follows standard flows. There is no long-lived session state on the server.
Admin access requires explicit role assignment. Platform administration endpoints are protected by role-based access controls enforced at the API layer.
Billing and payment
All payment processing is handled by Stripe. Arkive does not store, process, or have access to credit card numbers or payment credentials.
Stripe webhook events are verified using cryptographic signature validation before processing. Event deduplication uses transaction-safe database operations to prevent double processing.
Webhook payloads stored for audit purposes have personally identifiable information (email, name, phone, address) stripped before storage.
Redirect URLs in the checkout flow are validated against a strict allowlist. Absolute URLs, protocol-relative URLs, backslash injection, and percent-encoded path traversals are all rejected.
Infrastructure
Arkive platforms run on dedicated infrastructure. We do not use shared hosting or multi-tenant compute environments where another customer's workload runs adjacent to ours.
Database connections use TLS. Backups are encrypted. Access to production systems is restricted and logged.
We do not use client-side analytics, tracking pixels, or third-party scripts beyond the payment processor (Stripe). There is no Google Analytics, no Facebook pixel, no ad network integration.
Responsible disclosure
If you discover a security vulnerability in any Arkive platform, please report it to security@arkivehq.com.
We will acknowledge receipt, investigate, and provide a timeline for resolution. We do not pursue legal action against good-faith security researchers.