Overview
| Layer | Protection |
|---|---|
| Encryption | AES-256-GCM envelope encryption (DEK/KEK), random IV, versioned ciphertext. |
| Passwords | Argon2id with transparent migration from bcrypt. |
| 2FA | TOTP encrypted at rest, single-use recovery codes, enforceable by organization. |
| JWT | Pinned HS256 algorithm to prevent algorithm confusion. |
| Tokens | SHA-256-hashed refresh tokens; revocable, with raw values never stored. |
| Rate limiting | Two layers: by IP before authentication and by user ID after authentication. |
| Access control | Checked on every route. Least privilege: new members are read-only. |
| Host locking | A locked key can only be sent to its authorized domain. |
| Show once / TTL | One-time key display or automatic expiration. |
| Circuit breaker | Disable a set to make all of its secrets unavailable. |
| Abuse prevention | Secret-reveal burst detection, blocking, and alerting. |
| Proxy | Bound to 127.0.0.1, constant-time token checks, anti-SSRF, and DNS pinning. |
| Audit | Every access is tracked in an immutable log; database updates and deletes are blocked. |
| Application | Strict CSP, HSTS, and X-Frame-Options. |
Two-factor authentication
TOTP-based 2FA works with Google Authenticator, Authy, and 1Password. An organization can require it: members without 2FA cannot access secrets until they enable it.Immutable audit log
Every access and change is recorded. The audit table is append-only: a database trigger prevents all updates and blocks deletion of records from the last 90 days. An attacker cannot erase recent traces. Older rows are removed automatically according to the retention policy.Trust model
Elding encrypts secrets at rest and serves them over HTTPS. The server decrypts them for
delivery to the proxy. This is a managed model, like AWS Secrets Manager, Doppler, or
Vault, rather than strict zero knowledge. The client-side promise still holds: secrets never
touch your disk or your application’s memory when using the proxy.