LORIIQ

Under the zero-knowledge model, servers store ciphertext blobs only. Item names, URLs, usernames, passwords, and notes are encrypted on the client before sync. The API rejects request bodies containing master passwords, plaintext vault fields, or decrypted snapshots (FORBIDDEN_REQUEST_KEYS in vault-blob.ts). Without each user's master password, stored blobs are not readable by design — assuming the crypto implementation is correct and master passwords are strong enough to resist offline guessing.

An attacker with PostgreSQL and GCS access would obtain account emails, RSA public keys, encrypted private keys, KDF parameters (Argon2id: 64 MiB, t=3, p=4), auth verifier hashes, encrypted vault blobs, blob hashes/sizes/versions, device records, session metadata, and audit logs (IP, user agent, timestamps). They would not obtain master passwords or decrypted vault contents. Offline attacks against stolen ciphertext remain possible — effectiveness depends on master password entropy, not on server-side controls.

No — and you should not interpret our architecture as metadata-free. Servers necessarily observe blob size, sync frequency, vault version, device identifiers, and audit events. Marketing that implies zero server-side metadata overstates engineering reality. Ciphertext-only applies to vault contents, not to operational telemetry.

We can disclose account and operational data we hold: email, encrypted vault blob, KDF parameters, public key, encrypted private key, device metadata, and audit logs. We cannot produce decrypted vault contents or master passwords — we do not possess them. Privacy policy §14 states this explicitly.

Master password loss without a saved recovery phrase means permanent vault loss for that ciphertext. New device or cleared browser is different: sign in, pull the encrypted vault, unlock with the same master password. A BIP39-style recovery phrase (when set up) wraps vault keys client-side and can restore after primary cloud wipe. Account password reset rotates the login verifier only and does not decrypt the vault. Use /recover with your phrase to set a new master password while keeping vault data.

Today: client-side minimum length of 12 characters only. A strength meter is advisory; dictionary passwords like password1234 can be created. The server never receives the master password and cannot validate its entropy. Password-strength scoring exists for generated item passwords but is not enforced on the master password — this is an open gap.

Not yet. Interim controls include email verification, per-device sessions with revoke, login lockout/rate limits, and new-device email notification. TOTP and WebAuthn/FIDO2 are roadmapped (P0 in product spec) but not implemented in the API. Do not treat MFA as available for deployment decisions today.

OTP codes are hashed at rest (codeHash field) using a pepper derived from JWT_ACCESS_SECRET. Plaintext codes are sent only to email (and a test sink in non-production). Pending OTP rows are invalidated on schema deploy — expected behavior.

Google Cloud Platform — project loriiq, region us-central1. API on Cloud Run, PostgreSQL on Cloud SQL, vault blobs in GCS (gs://loriiq-vault-blobs). Secrets (JWT, database URL, SMTP, sync handshake) are intended to be sourced from Secret Manager via deploy scripts. Dedicated service accounts are scripted for API and web tiers with scoped IAM (e.g. logging.logWriter for the web service account).

HTTPS/TLS to api.loriiq.com. Vault sync uses an additional transport layer: ephemeral X25519 key agreement, HKDF-SHA256 with info string FortressVault-Sync-v1, and AES-256-GCM wrap/unwrap per session. Legacy raw encryptedVault uploads and downloads without clientPublicKey are rejected (SYNC_TRANSPORT_REQUIRED). Production requires SYNC_HANDSHAKE_SECRET (32+ chars) for sealed handshake tokens.

Not automatically. Our last infrastructure review identified drift between scripted intent and live configuration: loriiq-sync-handshake secret, dedicated web service account IAM, and removal of legacy Firebase logging sinks require reconcile via setup-gcp-compliance.sh, setup-gcp-logging-hipaa.sh, and redeploy scripts. Treat script-validated posture as intent until reconcile is re-run and confirmed.

Not as a user-facing control. Building or running the web app without NEXT_PUBLIC_API_URL disables sync and keeps the vault in IndexedDB only — a deploy-time condition, not an enterprise toggle. Self-hosted and export-only modes are planned but not productized.

No. SOC 2 Type II and HIPAA compliance work with Vanta is paid and actively in progress — not certified, and we do not claim outcomes we have not earned. Vanta covers compliance process and control evidence; it does not substitute for an independent cryptographic implementation audit.

No — this is the primary pre-GA security gate. Guarantees today are design intent plus unit/integration tests, not third-party validation. Scope intended for audit: @loriiq/crypto, client vault envelope, and KDF parameters. Trigger: before general availability and after major crypto changes.

Two layers: an internal penetration test was completed in July 2026 — findings are tracked and remediated internally. Separately, we have engaged an independent security firm for ethical hacking and third-party penetration testing; that engagement is underway and a formal report is pending. Neither substitutes for an independent cryptographic review or SOC 2/HIPAA certification work.

An operational IR document exists at docs/compliance/incident-response.md (severity levels, roles, containment playbooks, evidence retention). It has not been reported as exercised via tabletop drill. No published customer-facing breach notification policy or status page exists; GDPR 72-hour notification is referenced in internal planning docs only.

A compromised device defeats the model while the vault is unlocked. Malware can read memory (master key and decrypted snapshot), intercept keystrokes, scrape the DOM after autofill, and exfiltrate session tokens. Auto-lock (default 15 minutes; lock after the tab stays hidden for 5 minutes on web) and Argon2id reduce exposure windows but do not eliminate endpoint risk. This is out of scope for any client-side encryption architecture.

Vault item copy and the password generator use a 30-second best-effort auto-clear. Clipboard-monitor malware, OS clipboard history, and race reads before clear are not defended — inherent to any app that copies secrets for usability.

Content scripts run on all HTTP/HTTPS pages (standard for form detection). Autofill requires an explicit user click on an in-page chip or popup — pages cannot call the autofill API directly. Domain matching applies; phishing sites that trick a user into clicking remain a residual risk. Background handlers check vault-unlocked + domain match but do not verify user-gesture provenance.

Web app, browser extension, CLI, and desktop (Tauri) are in active development with client-side crypto and sync transport wired. Native mobile is not built. Enterprise features in the roadmap (SSO, SCIM, shared vaults, self-hosting) are not available for deployment evaluation against current builds.

Email security@vitatechgroup.com with reproduction steps. Coordinated disclosure is requested — do not disclose publicly until we have had reasonable time to investigate. No paid bug bounty program is published today; good-faith reports are acknowledged.

Core architecture is documented publicly on /security. Open-source release is deliberately deferred until after the independent cryptographic audit — closed source today is an explicit interim trust model, not an oversight.

Production dependencies include Google Cloud (compute, SQL, storage, Secret Manager, logging), email delivery via configured SMTP, and Vanta for compliance workflow. A formal subprocessor list with DPAs/BAAs for enterprise due diligence has not been published in this repository — request current documentation directly before contract review.