# Storehouses Security **A Security White Paper** Version 1.0 | June 2026 --- ## Table of Contents 1. [Executive Summary](#1-executive-summary) 2. [Security Philosophy](#2-security-philosophy) 3. [Threat Model](#3-threat-model) 4. [End-to-End Encryption](#4-end-to-end-encryption) 5. [Authentication & Access Control](#5-authentication--access-control) 6. [Audit Logging & Tamper-Evident Records](#6-audit-logging--tamper-evident-records) 7. [Infrastructure & Vendor Security](#7-infrastructure--vendor-security) 8. [Compliance & Independent Assurance](#8-compliance--independent-assurance) 9. [Incident Response & Vulnerability Disclosure](#9-incident-response--vulnerability-disclosure) 10. [Customer Responsibilities](#10-customer-responsibilities) 11. [Contact](#11-contact) --- ## 1. Executive Summary Storehouses is a privacy-first platform for managing high-value physical assets — precious metals, fine art, luxury watches, rare coins, wine, jewelry, and other collectibles. Because the data we hold is uniquely sensitive — a map of what an individual owns and where it is physically located — we treat security as the foundation of the product, not a feature. This paper describes how Storehouses protects customer data. The summary: - Sensitive customer data is end-to-end encrypted in the browser before it reaches our servers. Storehouses cannot read encrypted fields, including item titles, descriptions, notes, serial numbers, locations, and uploaded documents. - Authentication is enforced with multi-factor authentication, password policies that exceed industry baselines, and session controls that limit exposure on shared or stolen devices. - Every administrative and high-impact action is recorded in tamper-evident audit logs cryptographically linked into a hash chain. - The platform is built on infrastructure providers (Supabase, Vercel, Cloudflare, AWS, Stripe) that themselves carry SOC 2 Type II attestations and clear data processing agreements. - Storehouses maintains an active SOC 2-aligned compliance program with continuous monitoring through Vanta, and publishes a public vulnerability disclosure program for security researchers. This document is written for prospects, partners, advisors, and security teams evaluating the platform. For a deeper architectural treatment, see the main Storehouses technical white paper. For our public-facing posture and a path to report a finding, see `storehouses.app/security`. --- ## 2. Security Philosophy Storehouses is built on three principles that shape every security decision in the product. **Privacy by architecture, not by policy.** A privacy policy is a promise. A zero-knowledge architecture is a mathematical guarantee. Where the data is sensitive enough to warrant it, Storehouses encrypts in the browser so that the server stores opaque blobs it cannot decrypt — even if compelled, even if compromised, even from the inside. **Defense in depth, with realistic threat modelling.** No single control is sufficient. We assume that any individual layer — a database, a vendor, an internal admin, a customer device — can be compromised, and we design so that no single compromise reveals data that customers expect to remain private. **Security that survives the founder.** A platform that holds estate records must remain secure across decades and across personnel changes. Our procedures are documented, automated where possible, and reviewed against a third-party compliance framework so that controls do not erode over time. --- ## 3. Threat Model Storehouses explicitly defends against the following classes of threat: | Threat | Mitigation | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Database breach at our primary data provider | All sensitive fields are stored as ciphertext. A full database dump reveals no readable customer content. | | Key store breach at our caching provider | Encryption keys are wrapped with a key derived from the user's password using a memory-hard function. Even with full key-store access, an attacker cannot decrypt without the user's password. | | Compromise of an internal administrator | The server is zero-knowledge. No internal account possesses a key that can decrypt user data. | | Unauthorized account access | Multi-factor authentication, sliding-window rate limits on authentication endpoints, and session lifetime controls. | | Brute-force or credential stuffing | Memory-hard key derivation (Argon2id) makes offline guessing computationally expensive. Sliding-window rate limits block online guessing. Common-password blocking rejects known-breached credentials. | | Data tampering | Audit logs are hash-chained. Any retroactive modification breaks the chain and is detectable on verification. | | Vendor compromise | Vendors are selected for SOC 2 / ISO 27001 posture, contracted under data processing agreements, and reviewed annually. Data minimization limits what each vendor sees. | We also document accepted residual risks honestly. The two most important: - **Account takeover with valid credentials and MFA grants access to decrypted data.** This is inherent to any system where the user must be able to read their own data. Strong authentication, session controls, and audit logging are our mitigations. - **Loss of both the password and the recovery key results in permanent, irrecoverable data loss.** This is an intentional property of true end-to-end encryption. Storehouses has no recovery path that bypasses the user's own credentials, by design. --- ## 4. End-to-End Encryption For features that handle sensitive content, Storehouses implements field-level and file-level end-to-end encryption. **What is encrypted.** Item titles, descriptions, notes, seller information, serial numbers, certificate numbers, category-specific identifiers (brand, model, artist, producer, grade, etc.), storage location names and descriptions, collection metadata, and the contents of uploaded documents in Secure Storage. **What remains in plaintext.** Structural and numeric fields needed to deliver core platform value — category, quantity, weight, purity, purchase price, market value, and creation timestamps. This is a deliberate tradeoff. Keeping numeric fields in plaintext lets the platform calculate portfolio totals, run spot-pricing comparisons, evaluate price alerts, and serve aggregate analytics, while the identifying details of each item are protected. **Algorithms and key management.** Encryption uses AES-256-GCM with a randomly generated, per-field 96-bit initialization vector. Encryption keys are derived from the user's password using Argon2id — a memory-hard key derivation function selected for its resistance to GPU and ASIC attack acceleration. The derived key wraps a Master Encryption Key (MEK) that in turn encrypts user data. The MEK never leaves the browser in plaintext form. The server stores only the wrapped MEK and a salt; without the user's password, neither value is useful to an attacker. **Recovery.** A randomly generated 256-bit recovery key provides an independent path to unwrap the MEK if the user loses their password. The recovery key is presented to the user once during account setup and is the user's responsibility to safeguard. Storehouses does not retain a usable copy. **Sharing and heir access.** Share links and heir access use asymmetric encryption (X25519 ECDH with XSalsa20-Poly1305, via the NaCl `box` construction). When a user grants access, a copy of the relevant decryption key is wrapped with the recipient's public key. The recipient unwraps it client-side. Storehouses servers facilitate the exchange but never possess the underlying decryption material. --- ## 5. Authentication & Access Control **Identity provider.** Authentication is delegated to Supabase Auth, a SOC 2-attested identity service. Storehouses does not store passwords directly; Supabase stores them as scrypt-hashed values. **Password policy.** A minimum of 12 characters, with required uppercase, lowercase, numeric, and special-character classes. Common-password lists are checked at registration and password change to block known-breached credentials. **Multi-factor authentication.** TOTP-based MFA is supported and required for Pro and Lifetime customers. Users may enroll any standard authenticator (1Password, Authy, Google Authenticator, etc.). For Storehouses staff, MFA is mandatory across all administrative systems. **Session management.** Sessions issue secure, `HttpOnly`, `SameSite` cookies over TLS 1.3 only. An idle timeout of 30 minutes prompts the user for re-authentication, with a visible warning before expiration. Sessions are bound to the issuing device's fingerprint, and unusual session activity is logged for review. **Rate limiting.** Authentication endpoints are protected by sliding-window rate limits backed by Upstash Redis. Limits are tiered: stricter limits on login and password-reset endpoints; more permissive limits on read endpoints. Limits are evaluated at the edge to absorb abuse before it reaches application logic. **Row-Level Security.** The PostgreSQL database enforces row-level security policies on every table. Application code that attempts to read or write data outside the requesting user's scope is rejected at the database layer, not just at the application layer. This is a defense-in-depth control: even an application-level vulnerability cannot return data the user is not authorized to see. --- ## 6. Audit Logging & Tamper-Evident Records Every action that modifies an asset, changes access, grants or revokes a share, or records a heir request is appended to an immutable audit log. **Hash chaining.** Each audit entry contains the SHA-256 hash of the entry that preceded it. Any retroactive modification of an earlier entry invalidates every subsequent entry's hash, and the platform can detect this on verification. This property makes the log tamper-evident in a way that simple timestamped logging is not. **What is recorded.** Account events (login, MFA enrollment, password change), item events (create, update, delete, value change beyond a threshold), access events (share link creation and access, heir access requests and grants), and administrative events (admin actions taken on the customer's behalf, with the operator's identity). **Centralized log aggregation.** Operational and security-relevant events flow to Axiom in structured JSON format for retention, search, and alerting. Logs are retained for at least 90 days for operational use; security-relevant subsets are retained for two years to support investigation and audit requirements. **Customer access.** Account holders can view the audit log for their own account. Wealth advisors and estate managers using the professional portal can view audit logs scoped to the client portfolios they manage, subject to permission controls. --- ## 7. Infrastructure & Vendor Security Storehouses is built on a small, deliberately chosen set of infrastructure providers. Each is reviewed for its security posture before adoption and assessed annually thereafter. | Function | Provider | Attestation | | ------------------------------------ | ---------------- | ------------------------------- | | Application hosting and edge | Vercel | SOC 2 Type II, ISO 27001 | | Primary database and authentication | Supabase | SOC 2 Type II, HIPAA | | Object storage (encrypted blobs) | Supabase Storage | SOC 2 Type II | | Key wrapping and rate limiting cache | Upstash | SOC 2 Type II | | Edge protection and DDoS mitigation | Cloudflare | SOC 2 Type II, ISO 27001 | | Key management for backend secrets | AWS KMS | SOC 2 Type II, FedRAMP, PCI DSS | | Payment processing | Stripe | PCI DSS Level 1 | | Transactional email | Resend | SOC 2 Type II | | Operational logging | Axiom | SOC 2 Type II | | Customer support messaging | Intercom | SOC 2 Type II, ISO 27001 | **Data processing agreements** are in place with all vendors that handle customer data. Cross-border transfers rely on Standard Contractual Clauses where applicable. **Data minimization.** Each vendor receives only the data it requires. Stripe receives billing identifiers; Intercom receives the customer email and subscription tier; Resend receives the destination email and template variables. Sensitive asset content — the encrypted material at the heart of the platform — does not leave Supabase, and even there it is stored as ciphertext. **Continuous monitoring.** Vanta continuously evaluates the configuration of these vendors against the relevant SOC 2 controls and surfaces drift in real time. --- ## 8. Compliance & Independent Assurance Storehouses operates an active compliance program structured around SOC 2 Type II. **Continuous monitoring.** Vanta runs daily automated tests covering access management, change management, vulnerability management, vendor risk, and operational controls. Test results are reviewed continuously, and remediation is tracked against documented SLAs. **Vendor risk reviews.** All high-risk vendors are formally assessed annually. The current SOC 2 / ISO reports of every infrastructure provider are reviewed for material findings, with notes recorded in the vendor management system. **Risk register.** A documented risk register identifies and assesses threats to confidentiality, integrity, and availability. Each risk has an assigned treatment plan — mitigation, transfer, acceptance, or avoidance — with documented controls and review cadence. **Change management.** All code changes are managed through version control with branch protection. Production deployments are gated through a documented promotion process and recorded for audit. A separate change management policy governs configuration and infrastructure changes outside the application codebase. **Personnel.** All personnel with production access complete general security awareness training and acknowledge the company's information security policy. Onboarding and offboarding follow a documented checklist that includes access provisioning and revocation. **Independent attestation.** Storehouses is working toward a SOC 2 Type II attestation. The compliance program is structured to support that audit and is reviewed by the same controls under Vanta's continuous monitoring framework in the interim. Current attestation status is published on the public security page. --- ## 9. Incident Response & Vulnerability Disclosure **Incident response.** Storehouses maintains a documented incident response procedure covering detection, triage, containment, eradication, recovery, and post-incident review. Security-relevant events trigger alerting through the centralized logging pipeline. A defined on-call ensures incidents are acknowledged outside business hours. **Customer notification.** In the event of a confirmed security incident affecting customer data, Storehouses notifies affected customers in accordance with applicable law. Notification includes the nature of the incident, the categories of data affected, the steps taken in response, and recommended actions for affected customers. **Vulnerability disclosure program.** Storehouses publishes a public vulnerability disclosure program for security researchers. Researchers may report findings through the channels documented at `storehouses.app/security/bug-bounty`. Good-faith research conducted in accordance with the published policy will not be subject to legal action. Verified findings are acknowledged, triaged against a documented severity scale, and remediated within defined SLAs. **Patch and vulnerability management.** Application dependencies are continuously scanned for known vulnerabilities through GitHub Dependabot. Critical and high-severity findings are triaged within defined SLAs (24 hours and 7 days respectively). Automated security update PRs are enabled for non-breaking fixes. --- ## 10. Customer Responsibilities True end-to-end encryption depends on the customer holding their own credentials. Storehouses' security model places two specific responsibilities on the customer: **Safeguard your password.** Your password is the primary unlock for your encrypted data. We enforce a strong password policy at registration. We recommend a password manager and a unique password that is not reused on any other service. **Safeguard your recovery key.** Your recovery key is the only independent path to recover your data if you lose your password. It is shown to you once during account setup. Store it in a secure location separate from your password — a password manager's secure notes, a physical safe, or an offline document. Storehouses cannot recover a lost recovery key, and we do not retain a usable copy. **Enable multi-factor authentication.** MFA significantly reduces the impact of a stolen password. It is required for Pro and Lifetime accounts and recommended for all customers. **Be cautious with share links and heir designations.** Anyone with a share link and its password can view the snapshot you shared. Heir access, once granted, provides access to encrypted data. Review your active share links and designated heirs periodically. --- ## 11. Contact For general questions about this paper or our security program: `security@storehouses.app` To report a security vulnerability: `storehouses.app/security/bug-bounty` For partner or enterprise security reviews, including vendor questionnaires and SOC 2 evidence requests: `security@storehouses.app` (please indicate "Vendor Review" in the subject line) --- _This white paper describes Storehouses' security posture as of June 2026. The platform's security program is reviewed and updated continuously, and specific technical controls may evolve. For the most current information, consult `storehouses.app/security` or contact us directly._