Last Updated: January 26, 2026

Tijori employs a zero-knowledge architecture where the server never sees plaintext secrets. All encryption and decryption happens client-side in the browser using the Web Crypto API.
Note: Project passcodes are verified server-side (the passcode is sent for verification but never stored), while secret values remain client-only.

User's Master Key (memorized)
    │
    ├── Hash (SHA-256 + salt) → Stored in DB for verification
    │
    └── Derive via PBKDF2 → Master CryptoKey
            │
            └── Encrypts Project Passcodes (for recovery)

Project Passcode (6-digit)
    │
    ├── Hash (SHA-256 + salt) → Stored in DB for verification
    │
    └── Derive via PBKDF2 → Project CryptoKey
            │
            └── Encrypts all Environment Variables

Share Creation (by owner/admin):
1. Decrypt selected variables with Project CryptoKey
2. Generate random 256-bit ShareKey
3. Encrypt variables with ShareKey → encryptedPayload
4. User enters 8+ character share passcode (alphanumeric)
5. Derive SharePassKey from share passcode + new salt
6. Encrypt ShareKey with SharePassKey → encryptedShareKey
7. Store encrypted data in Convex

Share Access (by recipient):
1. Recipient enters share passcode
2. Derive SharePassKey from passcode + stored salt
3. Decrypt ShareKey from encryptedShareKey
4. Decrypt variables from encryptedPayload
5. Display to user

• Provider: Clerk (OAuth 2.0 / JWT)
• Token Validation: ctx.auth.getUserIdentity() in all Convex functions
• User Binding: tokenIdentifier links Clerk identity to Convex user record

Three roles per project:

Every Convex mutation/query:

1. Validates JWT via getUserIdentity()
2. Looks up user in database
3. Checks project membership
4. Verifies role has required permission

• All connections use HTTPS/WSS
• Convex uses encrypted WebSocket connections
• Clerk handles OAuth flows over HTTPS

• CryptoKey objects stored in keyStore (Map)
• Cleared on logout (keyStore.clear())
• Cleared on project lock (keyStore.removeKey())
• Never persisted to localStorage/sessionStorage

Implemented via Nitro middleware and config:

• Project passcodes: Regex /^\d{6}$/ + maxLength={6} + non-digit stripping
• Share passcodes: 8+ alphanumeric characters
• Form validation before API calls

• All arguments use strict v.* validators
• Type-safe document IDs with v.id("table")
• No raw SQL (document database)
• Project passcodes are verified on the server using stored hashes; plaintext passcodes are not persisted

✅ Eavesdropping (encryption at rest + in transit) ✅ Server compromise (zero-knowledge design) ✅ XSS attacks (CSP + React's escaping) ✅ Clickjacking (X-Frame-Options: DENY) ✅ CSRF (Convex's token-based auth) ✅ IDOR (ownership verification on all resources) ✅ SQL Injection (N/A - document database) ✅ Unauthorized access (RBAC on all mutations)

⚠️ Client-side keyloggers (user's machine compromised) ⚠️ Shoulder surfing (physical access) ⚠️ Weak passcodes (short or low-entropy) ⚠️ Forgotten master key (no recovery possible by design)

• Never log secrets or keys (check console.log calls)
• Use deriveKey() for key derivation, never raw passwords
• Generate fresh IV/salt for every encryption
• Validate user identity in every Convex mutation
• Check project membership before resource access
• Use v.* validators for all mutation arguments
• Clear keys on logout/navigation

We take security seriously. If you discover a security vulnerability, please follow responsible disclosure:

1. Do NOT open a public GitHub issue for security vulnerabilities
2. Email security concerns to the project maintainers
3. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Any suggested fixes (optional)

Security researchers who report valid vulnerabilities will be:

• Credited in our changelog (if desired)
• Added to our security acknowledgments

Thank you for helping keep Tijori secure!