Security Architecture
This page describes the security architecture of Vyntech Account — the cryptographic primitives, data protection mechanisms, infrastructure design, and threat model that protect your users' identity data.
Cryptographic Primitives
Password Hashing — Argon2id
All user passwords are hashed with Argon2id, the winner of the Password Hashing Competition. Argon2id combines data-dependent and data-independent memory access, providing resistance against both GPU-based cracking and side-channel attacks.
// Parameters Memory: 64 MB (65536 KiB) Iterations: 3 (time cost) Parallelism: 4 (lanes) Output: 32 bytes Salt: 16 bytes (crypto/rand)
Why not bcrypt?bcrypt is limited to 72 bytes of input and uses only 4 KB of memory, making it increasingly vulnerable to ASIC/FPGA attacks. Argon2id's configurable memory hardness (64 MB per hash) makes brute-force attacks economically impractical even with specialized hardware.
Token Signing — EdDSA (Ed25519)
All JWTs (access and refresh tokens) are signed with Ed25519, a modern elliptic-curve signature scheme using Curve25519.
Algorithm: EdDSA (Ed25519) Key size: 256-bit (32 bytes private, 32 bytes public) Signature: 64 bytes Performance: ~70,000 signatures/sec on commodity hardware
Why not RSA or ECDSA? Ed25519 produces smaller signatures (64 bytes vs 256+ for RSA), requires no padding (eliminating padding oracle attacks), provides deterministic signatures (no random nonce failures like ECDSA), and is significantly faster for both signing and verification.
HMAC — SHA-256
Webhook signatures and CSRF tokens use HMAC-SHA256. Each tenant has a unique webhook signing secret. CSRF tokens are bound to the user session and validated on every state-changing request.
// Webhook signature header X-Vyntech-Signature: sha256=<hex(HMAC-SHA256(secret, body))> // CSRF token structure HMAC-SHA256(session_secret, session_id + timestamp)
Random Generation — crypto/rand
All tokens, session IDs, API keys, recovery codes, and salts are generated using Go's crypto/randpackage — a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) backed by the operating system's entropy source (/dev/urandom on Linux, CNG on Windows). No math/rand is ever used for security-sensitive values.
Key Derivation — HKDF-SHA256
Sub-keys are derived from master secrets using HKDF (HMAC-based Key Derivation Function) with SHA-256. This allows a single master key to produce cryptographically independent keys for different purposes (encryption, signing, MAC) without key reuse.
// Key derivation example master_key = vault.GetMasterKey() enc_key = HKDF-SHA256(master_key, salt, "encryption") sign_key = HKDF-SHA256(master_key, salt, "signing") mac_key = HKDF-SHA256(master_key, salt, "mac")
Data Protection
Encryption at Rest
Sensitive fields — TOTP secrets, recovery codes, and API key hashes — are encrypted with AES-256-GCM before being written to the database. Each tenant has its own Data Encryption Key (DEK), which is itself wrapped by a Key Encryption Key (KEK) stored in Vault.
┌────────────────────────────────────────────────┐ │ Envelope Encryption │ ├────────────────────────────────────────────────┤ │ │ │ Vault (KEK) ──wraps──► Tenant DEK │ │ │ │ Tenant DEK ──encrypts──► TOTP secrets │ │ Recovery codes │ │ Sensitive fields │ │ │ │ Rotation: KEK every 90 days (auto) │ │ DEK re-wrapped on KEK rotation │ └────────────────────────────────────────────────┘
Encryption in Transit
- •TLS 1.3 minimum — older protocols are disabled at the load balancer
- •HSTS with preload —
max-age=63072000; includeSubDomains; preload - •Certificate pinning for internal service-to-service communication
- •OCSP stapling enabled for faster certificate validation
Database Security
PostgreSQL with Row-Level Security (RLS)policies enforces tenant isolation at the database engine level. Every table with tenant data has an RLS policy that restricts access to rows matching the current session's tenant_id. Even if application code has a bug, the database itself prevents cross-tenant data leakage.
Secrets Management
Master encryption keys, signing keys, and database credentials are stored in HashiCorp Vault with auto-unsealing. Keys are rotated automatically every 90 days. Application pods authenticate to Vault via Kubernetes service account tokens (short-lived, non-exportable).
Infrastructure Security
- •Isolated Kubernetes cluster with network policies — pods can only communicate with explicitly allowed services
- •No shared tenancy at infrastructure level — dedicated database schemas per security boundary
- •DDoS protection via Cloudflare with rate limiting at the edge before traffic reaches origin servers
- •Zero-trust internal networking — mTLS (mutual TLS) between all services; no implicit trust based on network location
- •Immutable infrastructure — container images are signed (cosign) and verified at deploy time; no SSH access to production nodes
- •Secrets injection at runtime — no secrets baked into images or environment variables; all secrets fetched from Vault at pod startup
Tenant Isolation
Tenant isolation is enforced at multiple layers to ensure that no single vulnerability can lead to cross-tenant data access:
- •ORM-level enforcement — every database query automatically includes
tenant_idin the WHERE clause, enforced by a query middleware that cannot be bypassed - •Row-Level Security — PostgreSQL RLS policies prevent cross-tenant data access even in the event of SQL injection
- •Token scoping— API keys and JWT tokens are cryptographically bound to a single tenant; tokens cannot be used to access another tenant's resources
- •Partitioned audit logs — audit entries are partitioned by tenant_id; log queries are scoped and cannot return entries from other tenants
Defense in depth: Even if the application layer is compromised, the database RLS policies act as an independent security boundary. An attacker who gains access to the application cannot query data outside the current tenant context without also compromising the database role configuration.
Threat Model
The following table describes the primary threats we defend against and the corresponding mitigations built into the platform:
| Threat | Mitigations |
|---|---|
| Credential Stuffing | Rate limiting, behavioral risk engine, progressive account lockout, breached password detection |
| Token Theft | Short-lived access tokens (15min), refresh token rotation on every use, reuse detection with automatic session revocation |
| Session Hijacking | Device fingerprinting, optional IP binding, Secure + HttpOnly + SameSite cookie flags, session anomaly detection |
| SQL Injection | Parameterized queries (no string interpolation), ORM enforcement, Row-Level Security as defense-in-depth |
| XSS | Strict Content-Security-Policy headers, HttpOnly cookies (no JS access to tokens), no inline scripts allowed |
| Insider Threat | Immutable audit logging, least-privilege access model, automatic key rotation, no single point of compromise |
Audit & Monitoring
Every security-relevant event is captured in an immutable, append-only audit log:
- •Authentication attempts (success and failure)
- •Token issuance and refresh events
- •Settings changes (security policies, branding, access control)
- •Admin actions (user suspension, role assignment, session revocation)
- •API key creation, rotation, and deletion
- •Risk engine decisions (challenge, block)
Logs are immutable (append-only, no deletion or modification), retained for 1 year (enterprise plan), and queryable via API for integration with external SIEM systems. Each entry includes actor, IP, timestamp, resource, action, and result.
Incident Response
Automated alerting and response mechanisms ensure rapid detection and containment:
- •Anomaly detection — automated alerts for mass failed logins, unusual admin activity, and key rotation failures
- •24/7 on-call — critical security events trigger immediate paging to the security team
- •User notification — confirmed breaches are communicated to affected users within 72 hours (GDPR Article 34 compliance)
- •Automatic containment — compromised sessions are revoked, affected tokens are blacklisted, and accounts are locked pending investigation
Regulatory compliance: Our incident response process is designed to meet GDPR (72-hour DPA notification), SOC 2 Type II (continuous monitoring), and ISO 27001 (Annex A.16) requirements.