Security & Compliance#

Comprehensive security architecture and compliance documentation for VAULT03.

Security Architecture#

End-to-End Encryption#

VAULT03 implements true end-to-end encryption:

  1. Client-side encryption: All files are encrypted in the browser before upload
  2. Server never sees plaintext: The server only stores encrypted chunks
  3. Client-side decryption: Downloaded files are decrypted only in the recipient’s browser
flowchart TB
    subgraph Upload["File Upload (Your Device)"]
        direction LR
        A[Original File] --> B[Compress]
        B --> C[Encrypt<br/>XChaCha20-Poly1305]
        C --> D[Split Chunks]
        D --> E[SHA256 Verify]
    end

    subgraph Server["VAULT03 Server"]
        F[(Encrypted<br/>Chunks Only)]
    end

    subgraph Download["File Download (Recipient Device)"]
        direction LR
        G[Download Chunks] --> H[Verify SHA256]
        H --> I[Decrypt]
        I --> J[Decompress]
        J --> K[Original File]
    end

    E -->|HTTPS| F
    F -->|HTTPS| G

    style C fill:#16a34a,color:#fff
    style I fill:#16a34a,color:#fff
    style F fill:#1e3a5f,color:#fff

Key Point: Encryption keys never leave your device. The server cannot read your files.

Cryptographic Primitives#

VAULT03 uses libsodium exclusively for all cryptographic operations:

Symmetric Encryption (SecretBox)#

  • Algorithm: XSalsa20-Poly1305
  • Key size: 256 bits
  • Nonce: 192 bits (randomly generated per encryption)
  • Authentication: Poly1305 MAC
  • Use cases:
    • Database field encryption (2FA codes, email passphrases)
    • Vault file encryption

Asymmetric Encryption (Box)#

  • Algorithm: Curve25519 + XSalsa20-Poly1305
  • Key size: 256 bits
  • Use cases:
    • Vault key sharing between users
    • Challenge-response authentication

File Encryption#

  • Algorithm: XChaCha20-Poly1305
  • Key size: 256 bits
  • Nonce: 192 bits (extended nonce for large files)
  • Chunk size: 4MB
  • Integrity: SHA256 per chunk

Password Hashing#

  • Algorithm: Argon2id
  • Memory: Moderate (64 MB)
  • Iterations: Moderate
  • Parallelism: 1
  • Salt: 128 bits (unique per user)
  • Output: 256 bits

Client-side hashing flow:

User Password → Argon2id(salt) → Client Hash → Send to Server
Server: Client Hash → Argon2(salt) → Server Hash → Store

This two-stage approach ensures:

  • Server never sees plaintext passwords
  • Protection against server-side database compromise
  • Server relief from expensive password hashing

Quantum-Resistant Signatures#

  • Algorithm: Dilithium3 (NIST PQC standard)
  • Key size: Public: 1,952 bytes, Private: 4,000 bytes
  • Use cases: File signatures (future feature)

Key Management#

Vault Keys#

  • Vault Signing Key: Dilithium3 key pair for vault attestation
  • Vault Sharing Key: Curve25519 key pair for asymmetric encryption
  • File Encryption Keys: Generated per-file using libsodium’s crypto_secretbox_keygen()

Keys are stored encrypted with user’s data password (derived via Argon2id).

Configuration Keys#

  • Database Encryption Key: 256-bit key for encrypting sensitive database fields
  • Inbox Encryption Key: 256-bit key for postal/email service queues
  • Deterministic Hashing Salt: 256-bit salt for deterministic user lookups
  • Server Auth Private Key: 256-bit key for server-side challenge generation

Key Generation:

cd api
go run tools/generate_secret_key/main.go  # 256-bit keys
go run tools/generate_key_pair/main.go    # Curve25519 or Dilithium key pairs

Authentication & Authorization#

Authentication Flow#

sequenceDiagram
    participant User
    participant Browser
    participant Server
    participant DB[(Database)]

    User->>Browser: Enter email + password
    Browser->>Server: Request salt
    Server->>DB: Get user salt
    DB-->>Server: Salt
    Server-->>Browser: Salt

    Browser->>Browser: Hash password (Argon2id)
    Browser->>Server: Send hash (not password!)
    Server->>Server: Hash again (Argon2id)
    Server->>DB: Compare with stored hash
    DB-->>Server: Match result

    alt Valid credentials
        Server->>DB: Create session
        Server-->>Browser: Session cookie (httpOnly)
        Browser-->>User: Login successful
    else Invalid credentials
        Server-->>Browser: Error
        Browser-->>User: Login failed
    end
  1. User enters credentials (email + password)
  2. Client fetches salt from /account/login/email
  3. Client hashes password with Argon2id
  4. Client sends hash to /account/login
  5. Server hashes again and compares with stored hash
  6. Server creates session if match
  7. Session stored in httpOnly cookie

Two-Factor Authentication (2FA)#

Supported methods:

  • SMS: 6-digit code sent via SMS gateway
  • Email: 6-digit code sent via email
  • TOTP: Time-based one-time password (RFC 6238)

2FA flow:

  1. Primary authentication succeeds
  2. Server generates 6-digit code (SMS/Email) or validates TOTP
  3. Code encrypted with database encryption key before storage
  4. User enters code
  5. Server decrypts and validates with constant-time comparison
  6. Session granted on success

TOTP details:

  • Algorithm: SHA1 (per RFC 6238)
  • Period: 30 seconds
  • Digits: 6
  • Backup codes: 10 pre-generated, bcrypt-hashed

Session Management#

  • Storage: httpOnly cookies (XSS protection)
  • SameSite: Strict in production, Lax in development
  • Secure flag: Always true (HTTPS only)
  • Duration: 4 hours
  • Partitioned: True in development (for cross-origin testing)

Rate Limiting#

  • Authentication endpoints: 5 requests per 15 minutes per IP
  • General API: 20 requests per 5 minutes per IP
  • Algorithm: Sliding window with automatic cleanup
  • Enforcement: Application layer + nginx layer

Multi-Tenancy Security#

flowchart TB
    subgraph Customers["Customer Tenants"]
        C1[Customer A<br/>acme.vault03.com]
        C2[Customer B<br/>corp.vault03.com]
        C3[Customer C<br/>org.vault03.com]
    end

    subgraph Isolation["Complete Isolation"]
        subgraph DB["Database"]
            D1[(A's Data)]
            D2[(B's Data)]
            D3[(C's Data)]
        end

        subgraph Files["File Storage"]
            F1[/acme/files/]
            F2[/corp/files/]
            F3[/org/files/]
        end

        subgraph Audit["Audit Logs"]
            A1[A's Logs]
            A2[B's Logs]
            A3[C's Logs]
        end
    end

    C1 --> D1 & F1 & A1
    C2 --> D2 & F2 & A2
    C3 --> D3 & F3 & A3

    style D1 fill:#3b82f6,color:#fff
    style D2 fill:#16a34a,color:#fff
    style D3 fill:#f59e0b,color:#000

Customer Isolation#

  • Database level: All queries scoped by customer_id
  • File storage: Separate directories per customer (data/files/{subdomain}/)
  • Audit logs: Required customer_id on all entries
  • API middleware: Validates customer context on all requests

Super-Admin Access#

  • 0x6c subdomain: Users from 0x6c.com subdomain are super-admins
  • Impersonation: Can view/edit any customer with impersonate-customer-id header
  • Audit trail: All impersonation actions logged
  • Use cases: Support, troubleshooting, compliance investigations

Data Protection#

Data at Rest#

  • Database:

    • Sensitive fields encrypted (2FA codes, email passphrases, verification tokens)
    • Database file permissions: 640 (owner read/write only)
    • Encryption key stored separately from database

  • Files:

    • Already encrypted client-side before upload
    • Server stores only encrypted chunks
    • Directory permissions: 750 (owner + group only)

  • Backups:

    • Encrypted with same keys as production
    • Stored with restrictive permissions (600)
    • Off-site backups use encrypted transport

Data in Transit#

  • HTTPS: TLS 1.2+ with strong cipher suites
  • Certificate: Let’s Encrypt with auto-renewal
  • HSTS: Enabled with 1-year max-age
  • Security headers:
    • X-Frame-Options: DENY
    • X-Content-Type-Options: nosniff
    • X-XSS-Protection: 1; mode=block
    • Referrer-Policy: strict-origin-when-cross-origin

Data Deletion#

Soft delete:

  • Records marked with deleted_at timestamp
  • Remains in database and backups
  • Appropriate for business records and audit trail

Hard delete:

  • Use Unscoped().Delete() to permanently remove
  • Required for:
    • GDPR “Right to be forgotten” requests
    • CCPA data deletion requests
    • Sensitive data removal
  • Affects database only - file cleanup separate

File deletion:

  • Database record deleted (soft or hard)
  • Physical files remain until expiration cleanup
  • Background job purges expired files

CSRF Protection#

Primary mechanism: SameSite cookies

  • Production: SameSite=Strict - strongest protection
  • Development: SameSite=Lax - protection + dev workflow

Why no CSRF tokens needed:

  • SameSite cookies prevent cross-site request forgery by design
  • Modern browsers support SameSite (98%+ coverage)
  • Defense in depth: httpOnly cookies prevent XSS token theft

Input Validation#

  • Server-side validation: All inputs validated with go-playground/validator
  • Email format: RFC 5322 compliant
  • Password strength: Minimum 5 characters (configurable)
  • Filename sanitization: Path traversal prevention
  • SQL injection: Prevented by GORM parameterized queries
  • XSS prevention: Vue.js automatic escaping + CSP headers

Audit Logging#

Every database operation is logged:

  • Entity type: Table name (users, vaults, vault_files, etc.)
  • Entity ID: Primary key of affected record
  • Action: Create, Update, Delete
  • Timestamp: UTC timestamp
  • Customer ID: Multi-tenancy context (required)
  • Changed by: Person ID who performed action
  • Changes: JSON diff of before/after state
  • Metadata: Optional context (IP, user agent, etc.)

Immutability: Audit logs have no soft delete - kept forever for compliance.

Access: Database-level access only (no API endpoints for security).

Compliance#

GDPR (General Data Protection Regulation)#

Data subject rights:

  1. Right to access: Users can view their data via UI
  2. Right to rectification: Users can update their profile
  3. Right to erasure (“Right to be forgotten”):
    • Hard delete required: db.Unscoped().Delete()
    • Removes personal data from database
    • Files deleted from storage
    • Backups: Documented retention policy required
  4. Right to data portability: Export vault files via download
  5. Right to restrict processing: Soft delete (account suspension)
  6. Right to object: Opt-out of non-essential processing

Data protection by design:

  • End-to-end encryption (confidentiality)
  • Multi-tenancy isolation (data segregation)
  • Audit logging (accountability)
  • Access controls (integrity)
  • Regular backups (availability)

Data processing records:

  • Maintain records of what data is processed
  • Document purposes and legal bases
  • Data retention policies
  • Third-party processors (email/SMS providers)

Breach notification:

  • 72-hour notification to supervisory authority
  • Without undue delay to affected data subjects
  • Audit logs aid in breach investigation

CCPA (California Consumer Privacy Act)#

Similar requirements to GDPR:

  • Right to know what data is collected
  • Right to delete personal data
  • Right to opt-out of sale (not applicable - no data sale)
  • Non-discrimination for exercising rights

ISO 27001 Preparation#

Information Security Management System (ISMS) controls:

  • A.9 Access Control: Role-based access, 2FA, session management
  • A.10 Cryptography: libsodium for all crypto, key management
  • A.12 Operations Security: Audit logging, backups, monitoring
  • A.13 Communications Security: TLS, security headers, CSRF protection
  • A.14 System Acquisition: Secure development lifecycle
  • A.16 Incident Management: Audit trail for investigation
  • A.17 Business Continuity: Backup and restore procedures
  • A.18 Compliance: Audit logs, data protection measures

Data Retention#

Recommended policies:

  • Active user data: Retained while account active
  • Deleted user data: Hard delete within 30 days
  • Audit logs: 7 years (compliance requirement)
  • Backups: 30 days rolling (configurable)
  • Expired shares: Immediate deletion by background job
  • Expired vaults: Based on customer configuration

Subprocessors#

Data processors (if using third-party services):

  • Email provider: For 2FA and notifications (configure DPA)
  • SMS provider: For 2FA codes (configure DPA)

Recommendation: Use self-hosted or EU-based providers for GDPR compliance.

Security Best Practices#

Deployment#

  • Use HTTPS everywhere
  • Enable firewall (only SSH, HTTP, HTTPS)
  • Disable root SSH login
  • Use SSH keys (not passwords)
  • Keep system updated
  • Enable automatic security updates
  • Configure log monitoring
  • Set up intrusion detection (fail2ban)
  • Regular backups with off-site storage
  • Test restore procedures

Configuration#

  • Generate unique encryption keys for production
  • Never commit keys to version control
  • Use environment variables or secret management
  • Enable rate limiting (app + nginx)
  • Configure strong SSL/TLS settings
  • Set appropriate file permissions
  • Disable directory listing
  • Remove default accounts
  • Configure security headers

Operations#

  • Monitor logs daily
  • Review audit logs weekly
  • Rotate logs regularly
  • Test backups monthly
  • Update software quarterly
  • Review access controls
  • Conduct security assessments annually
  • Maintain incident response plan
  • Document procedures
  • Train staff on security

User Management#

  • Enforce strong passwords
  • Require 2FA for admins
  • Implement least privilege
  • Regular access reviews
  • Offboard users promptly
  • Monitor for suspicious activity
  • Educate users on security

Analytics & Privacy#

VAULT03 uses privacy-focused analytics (Umami) with strict controls:

flowchart LR
    subgraph Tracked["Marketing Pages Only"]
        HOME["/"]
        CONTACT["/contact"]
        PRIVACY["/privacy"]
        COOKIES["/cookies"]
    end

    subgraph NeverTracked["Never Tracked"]
        LOGIN["/login"]
        TFA["/2fa/*"]
        VAULT["/vault/*"]
        FILES["/v/* (file access)"]
        AUTH["Authenticated pages"]
    end

    Tracked -->|"Anonymous pageviews"| UMAMI[("Umami")]
    NeverTracked -.->|"Script removed"| NONE["No data collected"]

    style Tracked fill:#d4edda
    style NeverTracked fill:#f8d7da
    style NONE fill:#f8d7da

Privacy controls:

  • Marketing pages only - Analytics script loads only on /, /contact, /privacy, /cookies
  • Script removal - When navigating to sensitive pages, the script is completely removed from the page (not just disabled)
  • No tracking on:
    • Login and password reset pages
    • Two-factor authentication pages
    • Vault creation, viewing, or file operations
    • Any authenticated pages
    • Data password entry
  • Do Not Track - Respects browser DNT setting
  • No cookies - Umami uses cookieless tracking
  • Self-hosted option - Can run your own Umami instance
  • GDPR compliant - No personal data collected, no consent required

Why this matters:

  1. Credential protection - No third-party scripts run during login
  2. File privacy - Vault URLs and file operations are never tracked
  3. Minimal surface - Analytics code only present on 4 marketing pages
  4. Verifiable - Open source implementation, auditable

Vulnerability Reporting#

Responsible disclosure:

  • Email: security@vault03.com
  • GPG key: Available on website
  • Response time: Within 48 hours
  • Coordinated disclosure: 90 days

What to include:

  • Detailed description
  • Steps to reproduce
  • Proof of concept (if safe)
  • Impact assessment
  • Suggested fix (if available)

Security Changelog#

Version 1.0 (Current):

  • ✅ All 21 CRITICAL vulnerabilities resolved
  • ✅ Foreign key constraints
  • ✅ Email uniqueness
  • ✅ Rate limiting
  • ✅ 2FA code encryption
  • ✅ Email passphrase encryption
  • ✅ Email verification
  • ✅ CSRF protection (SameSite cookies)
  • ✅ Audit log integrity
  • ✅ Race condition fixes
  • ✅ Transaction atomicity
  • ✅ XSS protection (httpOnly cookies)
  • ✅ URL fragment key clearing

Additional Resources#

Contact#

For security questions and concerns:

Backward Operations Guide Support Forward