SECURITY · RESPONSIBLE DISCLOSURE

Security at LockTime.

We build LockTime around a simple promise: encrypt before it leaves your device. This page describes what we encrypt, where we still rely on trust, and how to report a vulnerability.

THREAT MODEL

What we protect against — and what we don't.

LockTime is designed for two layered modes. Convenience mode stores your vault ciphertext on our infrastructure, encrypted with a key derived from your authenticated session — useful, but it means a server compromise combined with auth-secret exposure could decrypt. Zero-knowledge mode stacks a passphrase-derived key (PBKDF2-SHA256, 600,000 iterations) on top — the passphrase never touches our servers, and there is no recovery if you lose it.

We protect against passive observers, infrastructure leaks of stored data, and most categories of server compromise. We do not defend against malware on your device, browser extensions with full DOM access, or coercion. We are also not a substitute for a hardware security key for high-value secrets — if you're storing something worth a six-figure attack, layer a YubiKey on top.

WHAT'S ENCRYPTED

Cipher, keys, and storage.

Cipher

AES-GCM-256 (authenticated encryption)

Vault key derivation

HMAC-SHA256(account secret, user-id) — convenience mode

ZK key derivation

PBKDF2-SHA256, 600,000 iterations, 16-byte salt

Time-lock proof

Cloudflare drand beacon for unbiased future randomness

Capsule contents

Encrypted client-side. Server stores ciphertext only.

Vault entries

Encrypted client-side before upload to Vercel Blob.

Notification metadata

Recipient email, capsule title, share URL — encrypted at rest (server-side, separate key).

Short-link targets

Target URL and title encrypted at rest (premium feature).

Auth credentials

Handled by Clerk. We never see your password.

Transport

TLS 1.3, HSTS preload (2-year max-age, includeSubDomains).

HARDENING

Defense in depth.

Strict Content-Security-Policy with allowlisted origins, no unsafe-eval.
X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin.
Cross-Origin-Opener-Policy + Permissions-Policy to disable unused powerful browser features.
Per-user, per-action rate limits on every authenticated endpoint, backed by Postgres so they survive serverless restarts.
Off-domain redirect interstitial on short links — recipients see the destination host before continuing.
Two-factor authentication available via Clerk; we surface a prompt in your account settings.
Webhooks (Clerk, cron) are signed and verified server-side; cron endpoints reject unauthenticated callers.

REPORTING A VULNERABILITY

Found something? Tell us.

We welcome reports from researchers, hobbyists, and curious users. Please email us with reproduction steps, affected URLs or endpoints, and your handle if you'd like credit.

Please do: report privately first, give us a reasonable window to fix, test only against your own accounts.
Please don't: run automated scanners that generate load, access other users' data, or publicly disclose before we've responded.
We aim to acknowledge reports within 72 hours and triage within a week.

REWARDS

Ad-hoc bounties.

We don't run a formal bounty platform yet. For valid, novel reports we may pay a discretionary reward scaled to severity and impact. Public credit on this page is offered with your permission.

OUT OF SCOPE

What we won't pay for.

Self-XSS, missing security headers without a working exploit, clickjacking on pages with no sensitive actions.
Rate-limit findings that require unrealistic budgets to demonstrate.
Reports generated by automated scanners with no manual validation.
Issues in third-party services we depend on (Clerk, Vercel, Resend) — please report those upstream.
Social engineering of LockTime staff or our customers.

See also: /.well-known/security.txt