Defense in Depth¶
Security is not a feature — it's the architecture. Trading platforms handle real money and broker credentials. A single vulnerability can mean unauthorized trades, stolen API keys, or drained accounts. 4pass implements 5 layers of defense-in-depth, ensuring that no single layer failure compromises the system. Every layer assumes the one above it has already been breached.
5 Security Layers¶
An attacker must defeat all 5 layers to reach trading operations. Each layer operates independently — compromising the WAF doesn't bypass authentication, and stealing a JWT doesn't decrypt broker credentials.
Security Summary¶
| Layer | Protection | Implementation | Attack Vectors Covered |
|---|---|---|---|
| Network | WAF rules, rate limiting, IP filtering | AWS WAFv2 with 7 rules (admin IP restriction, TradingView allowlist, login rate limit, blanket rate limit, 3 managed rule sets) | DDoS, brute force, SQL injection, XSS, known exploits, bot traffic |
| Transport | TLS encryption, strict transport, secure cookies | ALB + ACM auto-renewing certificates, HSTS 1yr with preload, SameSite=strict |
MITM, session hijacking, cookie theft, protocol downgrade |
| Authentication | Multi-factor verification, session management | JWT (HS256) + Argon2id + Cloudflare Turnstile CAPTCHA + per-session CSRF tokens | Credential stuffing, brute force, session fixation, CSRF |
| Encryption | End-to-end credential protection | RSA-4096 (KMS HSM) + AES-256-GCM + per-user isolation keys | Data breach, credential theft, insider threat, memory dump |
| Application | Webhook validation, audit trail, attack detection | 4-layer webhook defense, Redis replay detection, real-time email alerts | Replay attacks, unauthorized trading, webhook forgery |
Key Security Properties¶
Credentials Are Never Stored in Plaintext
Broker API keys and secrets are encrypted with per-user AES-256-GCM keys before touching the database. Even a full database dump reveals nothing without the corresponding encryption keys.
RSA Private Key Never Leaves Hardware
The RSA-4096 private key used for frontend-to-backend encryption is managed by AWS KMS and stored in a FIPS 140-2 Level 3 Hardware Security Module. The key cannot be exported, extracted, or accessed in software — all decryption happens inside the HSM.
- Per-user encryption keys — compromising one user's key doesn't affect any other user. Each trading account has a unique 32-byte encryption key, itself encrypted with the master key.
- All security events are audited and alertable — the
audit_logstable records every authentication attempt, webhook request, attack detection, and administrative action with full request context. - Constant-time comparisons prevent timing attacks — all secret comparisons (webhook secrets, CSRF tokens, API keys) use
hmac.compare_digest()to eliminate timing side channels. - Replay detection with Redis-based deduplication — SHA-256 hashes of webhook payloads are stored in Redis with TTL-based expiration, preventing captured requests from being replayed.
- Fail-open rate limiting — application-level rate limits use Redis sorted set sliding windows but fail open on Redis errors, ensuring trading operations are never blocked by cache failures.
Compliance and Standards¶
For security-conscious evaluators
4pass implements FIPS 140-2 Level 3 HSM-backed encryption, OWASP-recommended password hashing, and comprehensive audit logging. To decrypt a single user's broker credentials, an attacker must simultaneously possess: (1) database access, (2) KMS Decrypt IAM permission, and (3) the specific per-account encryption key. Compromising any one alone reveals nothing.
| Standard | Implementation |
|---|---|
| FIPS 140-2 Level 3 | AWS KMS HSM for RSA-4096 key storage and all asymmetric decryption operations. Private key never exists in software memory. |
| OWASP Password Guidelines | Argon2id (memory-hard, GPU-resistant) via pwdlib — the OWASP-recommended and PHC-winning password hashing algorithm |
| Security Headers | HSTS (1 year + includeSubDomains + preload), CSP, X-Frame-Options SAMEORIGIN, X-Content-Type-Options nosniff, COOP, CORP, Referrer-Policy, Permissions-Policy |
| Audit Trail | Complete audit logging for all state-changing operations — user ID, IP address, User-Agent, request path, success/failure, error messages, and arbitrary metadata JSON. 90-day retention in primary DB; S3 archive for long-term compliance. |
| Encryption at Rest | AES-256-GCM for credential storage, envelope encryption with KMS for key management. Per-user key isolation — compromising one account key reveals nothing about others. |
| Encryption in Transit | TLS 1.2+ via ALB + ACM, plus application-level RSA+AES hybrid encryption for credential submission. Double encryption layer — TLS failure alone does not expose credentials. |
| Constant-Time Comparisons | All secret comparisons (webhook secrets, CSRF tokens, API keys) use hmac.compare_digest() to eliminate timing side channels. |
Section Overview¶
This security section provides detailed coverage of each layer:
Authentication¶
JWT tokens, Argon2id passwords, session management, CSRF protection, Cloudflare Turnstile CAPTCHA, API keys, IP whitelisting, and the complete middleware stack.
Encryption¶
RSA-4096 + AES-256-GCM hybrid encryption, AWS KMS HSM integration, per-user key isolation, encryption versioning, and the complete key hierarchy from browser to database.
Webhook Security¶
4-layer mandatory validation for TradingView webhooks — unique URL tokens, timestamp verification, secret authentication with constant-time comparison, and Redis-based replay detection.
Attack Detection¶
AWS WAF rules, application-level rate limiting, real-time attack classification, email alerting with rate limiting, comprehensive audit logging, and security headers.