NineAuth Security Architecture & Threat Model
A transparent breakdown of our cryptographic choices, threat model, and zero-trust runtime guarantees.
1. Threat Model & Client-Side Reality
Any binary running on an end-user's machine can theoretically be decompiled, patched, or memory-injected. NineAuth explicitly operates under this premise. We never trust client-side boolean checks alone. Every critical feature gate and resource access is validated against our hardened server runtime, ensuring that patching a local binary yields zero unauthorized server access.
2. Token Storage & Cryptography
NineAuth issues 256-bit cryptographically secure opaque tokens generated via Node.js crypto.randomBytes. Tokens are never JWTs with decoded privileges; they are indexed in PostgreSQL using SHA-256 digests. This guarantees that compromised client tokens cannot be forged or manipulated offline.
3. Password & Credential Protection
End-user credentials are encrypted using Argon2id with strict memory and iteration cost parameters (m=65536, t=3, p=4), exceeding OWASP security recommendations and defending against specialized GPU/ASIC brute-force attacks.
4. Hardware Fingerprinting (HWID)
Hardware bindings evaluate physical CPU, motherboard, and system UUID parameters. To protect user privacy, identifiers are one-way hashed before transmission, preventing hardware reconstruction while ensuring strict per-device activation quotas.
5. Cascade Session Revocation
Revoking a license, banning a user, or deactivating an application in the dashboard triggers an atomic purge across all active session tokens and cached entitlement states in under 50 milliseconds.
Responsible Vulnerability Disclosure
If you discover a security vulnerability in NineAuth infrastructure or SDKs, please contact our security team directly at security@nineauth.xyz. We acknowledge reports within 12 hours and provide coordinated remediation timelines.
security@nineauth.xyz