Threat Model
No security product can protect against every possible threat. We believe that identifying and openly communicating our security boundaries and limitations is critical to building a mature security posture.
01. Security Boundaries
Our architectural threat model maps the separation of concerns between local hardware operations, local client boundaries, and third-party environment conditions.
Mitigated Threats
Vectors fully resolved by local-first design and offline vault architecture.
ZeroAuth stores no central server seed database. No remote honeypot exists to compromise.
FIDO2 / Passkey authentication protocols enforce origin-bound verification automatically.
OS Trust Required
Vectors requiring underlying host security and platform sandbox integrity.
Compromised OS sandboxes allow administrative memory reading and process interception.
Advanced malware recording screen buffers can capture seeds when actively displayed.
02. Threat Profiles
Detailed technical assessments of security boundaries, assumptions, and threat scenarios outside the scope of application-level cryptography.
Compromised Device
ZeroAuth protects credentials at rest and in transit, assuming the host OS is secure. A severely compromised device (malware, root, jailbreak) bypasses app-level isolation. A privileged attacker can intercept screen captures, log keystrokes, or read decrypted memory.
Social Engineering
Technical controls cannot prevent voluntary user action. If a user is manipulated into unlocking the vault, exporting keys, or transmitting unencrypted data, the security boundary is bypassed. We implement warnings, but user-initiated extraction cannot be prevented.
Phishing Limitations
Traditional TOTP codes protect against static leaks but remain vulnerable to real-time phishing proxies (Adversary-in-the-Middle). While ZeroAuth supports phishing-resistant passkeys (WebAuthn), their effectiveness depends entirely on service provider support.
Malicious Local Actor
If an unauthorized actor gains physical access to a device while the vault is active and unlocked, they have full access. ZeroAuth implements aggressive auto-lock timers to mitigate this exposure, but physical device security remains the user's responsibility.
03. Architectural Choices
Building a local-first authenticator requires deliberate architectural tradeoffs. Below is our formal assessment of convenience versus security parameters.
Local-First vs Cloud Recovery
Eliminates centralized servers and master seed databases. Zero risk of a mass cloud database breach.
No cloud recovery. If you lose your device and lack an encrypted backup, data is permanently unrecoverable.
Convenience vs Security
Provides OS-backed hardware-enclave biometric unlocks, trading a pure "what you know" defense for biometric verification.
Requires trusting the device biometric subsystems (FaceID/TouchID/Android Biometrics) to lock/unlock key storage.
Offline Survivability
Works 100% offline. Zero dependency on network connectivity or external servers.
No server-side brute-force throttling or lockouts. Relies entirely on local KDF work-factor iterations and secure enclave rate limits.
Security Advisory: Backup Vector Risks
Since the user assumes responsibility for their data availability, creating backups is essential. However, backups represent a secondary attack vector. If a user creates an encrypted backup of their vault and stores it in an insecure cloud environment with a weak, easily guessable password, they compromise their own security posture.