This page explains how the Altech toolkit stores, encrypts, and protects the information you enter. It describes how the application itself is engineered, in plain language first, with the precise technical controls below. It is a description of the build, not an independent audit or a compliance certification.
In plain language
🔐
Your data is encrypted
The client information you enter is encrypted with AES-256-GCM (the same 256-bit standard used to protect sensitive financial and government data) before it is synced to the cloud, and sensitive data is encrypted at rest on this device as well.
🔑
Only you can unlock it
With the secure vault enabled, your data is sealed with a key derived from your passphrase, which never leaves your device. The encryption key is never sent to the server, so neither we nor anyone with database access can read your data.
🧱
Each account is walled off
The database enforces per-account isolation at the row level. A signed-in user can never read another user's data; this is enforced by the database itself, not just by app code.
🛡️
Strong sign-in
Email and password sign-in with optional two-factor authentication (authenticator app or passkey/security key). Turning on cloud sync prompts for, and ultimately requires, two-factor.
💻
Works offline, stays local
When you're offline your work stays in your browser. Certain secrets (encryption salts, device passkeys, the activity log) are marked never-sync and never leave the device. Exported files (PDF, EZLynx, HawkSoft) are produced in your browser; the plaintext never passes through our servers.
🔒
Hardened connections
All traffic is HTTPS with strict-transport-security enforced, and every API request passes through hardened middleware (rate limiting, strict browser-security headers, request tracing).
▸ Technical detail (for IT / auditors)
Encryption & key management
- Cipher: AES-256-GCM (256-bit, authenticated) via the browser's Web Crypto API, with a fresh 96-bit (12-byte) random IV per record.
- Authenticated envelopes: cloud records use a versioned envelope whose GCM authentication tag is cryptographically bound (AAD) to the (table, row id, user id), so the server cannot move, swap, or relabel a ciphertext.
- Per-user master key: a random 256-bit key generated once per user, never sent to the server. It is wrapped (encrypted) twice: once with your passphrase, once with a one-time recovery key. Changing your passphrase only re-wraps the key; your data is not re-encrypted or exposed.
- Key derivation: new vaults use Argon2id (memory-hard, GPU-resistant; 64 MiB / 3 iterations / 1 lane). Older vaults remain on PBKDF2-SHA-256, 600,000 iterations; the legacy device-bound key uses PBKDF2-SHA-256, 100,000 iterations. Role subkeys are domain-separated with HKDF-SHA-256 so a leak in one context cannot be replayed against another.
- Key lifetime: the unwrapped key is held in memory and mirrored only into the browser tab's session storage so a page refresh doesn't re-prompt. It is bound to the signed-in account, is never placed in persistent local storage, and is cleared when the browser tab or window closes.
Data isolation: Row-Level Security
- All cloud data lives in PostgreSQL (Supabase) with Row-Level Security enabled on every user table; each row is scoped to the authenticated user id.
- A self-checking database migration refuses to deploy if any expected table is missing RLS or has zero policies, or if a new public table was not explicitly inventoried.
- An operator script independently verifies that cross-user reads return zero rows and cross-user writes are rejected.
Authentication & two-factor
- Supabase Auth (email + password). Every API call carries a bearer token that is verified server-side on each request.
- MFA: TOTP authenticator apps and WebAuthn passkeys / security keys. MFA is prompted and ultimately enforced when cloud sync is enabled.
- Account-block and admin flags are server-managed; a blocked account is signed out immediately.
API hardening & browser-security headers
- Per-identity rate limiting (anonymous by IP, authenticated by user), a CORS origin allow-list, and an X-Request-ID on every request for traceability.
- Strict-Transport-Security:
max-age=31536000; includeSubDomains (HTTPS forced for 1 year, all subdomains).
- Content-Security-Policy:
default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' (content restricted to the app's own origin).
- X-Frame-Options:
DENY (no clickjacking / framing).
- X-Content-Type-Options:
nosniff.
- Referrer-Policy:
strict-origin-when-cross-origin.
- Permissions-Policy:
camera=(), microphone=(), geolocation=() (disabled).
Data handling & your control
- Local-only by design: encryption / passphrase salts, device passkey material, the local activity log, and the sync opt-out flag are never synced.
- Exports (PDF, EZLynx XML, HawkSoft CMSMTF) are generated in your browser; the plaintext does not pass through our servers.
- You can disable cloud sync per device and delete all your cloud data at any time from Settings.
- Incident response: in the event of a suspected breach the principal is notified and the Washington RCW 19.255 notification timeline is followed.