What we defend. What we don't.
An honest accounting of every adversary AuthenSee was designed to defeat — and the ones we won't pretend to. A composable proof is only as good as its threat model; this is ours, written down.
Eight ways to fake a person.
Every authentication system inherits an adversary model — even the ones that pretend not to. Here are the eight we built against.
Phisher
How AuthenSee defeats itChallenges are bound to the verifier's domain and a per-session nonce. There is no shared secret to phish, and a stolen artifact won't replay anywhere else.
Credential stuffer
How AuthenSee defeats itNo password ever leaves the user's device, and commitments aren't replayable across sessions. Leaks of one verifier's audit trail reveal nothing usable elsewhere.
Deepfake operator
How AuthenSee defeats itThe memory factor cannot be reproduced from a public artifact — synthetic media has no signal for "what you remember." Liveness runs on-device and emits only a ZK commitment, not the biometric.
Sybil farm
How AuthenSee defeats itComposing multiple factors raises the per-account cost from cents to many dollars. Verifiers can require a higher bar (e.g. memory + liveness) on signup without changing the proof envelope.
MITM / replay
How AuthenSee defeats itEvery proof is bound to the verifier's challenge nonce. A captured proof cannot be re-bound to a fresh challenge — the soundness of the underlying SNARK is the floor.
Compromised IdP
How AuthenSee defeats itWe are factor-agnostic: no single IdP, vendor, or device enclave is trusted unilaterally. Trust is an AND across the active factors, not a transitive trust through one issuer.
Honest-but-curious verifier
How AuthenSee defeats itThe proof reveals exactly one bit: whether you authenticated. Factor templates, biometrics, device IDs, and answer payloads never cross the wire. Curiosity is mathematically unrewarded.
Profile linker
How AuthenSee defeats itProofs are unlinkable across verifiers by default. No persistent user identifier is emitted; rotating commitments make cross-site correlation cryptographically infeasible.
Per attacker, per factor.
Composition isn't decoration. Different attackers fall to different factors — that's why we let you pick. Green means the factor alone is enough; amber means it raises cost meaningfully; — means it doesn't help against this attacker (use a different one).
| Adversary | Passkey | Memory | Liveness | Hardware |
|---|---|---|---|---|
| Phisher | ✓ | ~ | — | ✓ |
| Credential stuffer | ✓ | ✓ | — | ✓ |
| Deepfake operator | — | ✓ | ~ | — |
| Sybil farm | ~ | ✓ | ✓ | ✓ |
| MITM / replay | ✓ | ✓ | ✓ | ✓ |
| Compromised IdP | ~ | ✓ | ✓ | ✓ |
| Honest-but-curious verifier | ✓ | ✓ | ✓ | ✓ |
| Profile linker | ✓ | ✓ | ✓ | ✓ |
The honest part.
A threat model is only useful if it draws a line. Here is everything AuthenSee does not claim to solve, in order of how often we get asked.
We are not identity
AuthenSee proves authentication — that the same actor is back. It does not establish who a person is in the legal or governmental sense. KYC, age verification, and citizenship are different problems with different proofs.
Compromised endpoint
If the device is rooted, screen-recorded, or running malware with kernel access, no auth protocol can save you — because the attacker becomes you. Hardware-backed factors raise the bar; they do not eliminate it.
Voluntary credential sharing
If a user hands their phone to a friend and walks them through a memory tile, the system has no way to detect this. It's the same failure mode as a borrowed badge — out of cryptography's reach.
Social-engineered recovery
A help-desk operator who can be sweet-talked into resetting a factor is a vulnerability AuthenSee cannot patch from inside the proof. Recovery is a separate workstream — design notes due Q4 2026.
Post-quantum, today
The current SNARK depends on assumptions that fall to a sufficiently large quantum computer. Our migration plan to a PQ-secure circuit is published in the spec and tracking with NIST's selections; expect rollout starting Q3 2026.
Verifier rate-limiting
AuthenSee proves a single attempt succeeded. Throttling, account lockouts, anomaly detection, and abuse signals belong to the verifier — we do not impose policy on top of cryptography.
What the math guarantees.
For the cryptographers in the room. Every property below is formally argued in the open spec; informal sketches here.
You can't fake the bit.
The verifier accepts a proof iff a valid witness exists. Forging a "verified" output without the underlying factor commitments requires breaking the SNARK — currently 2^128 work under standard assumptions.
The proof leaks nothing else.
Anything an honest-but-curious verifier learns from the proof, it could simulate from the public statement alone. No factor, template, or answer crosses the wire — that is the whole point of the protocol.
Many factors, one shape.
A proof generated from {passkey, memory} is indistinguishable from one generated from {passkey, liveness} for the same user. Verifiers cannot infer which factors a user composed unless they require it explicitly.
Proofs don't transplant.
A proof for verifier A with nonce n cannot be re-bound to verifier B or to a different nonce. Replay across sessions, services, or surfaces is cryptographically excluded.
Commitments don't betray you.
Per-factor commitments stored on-device hide the underlying secret with statistical (not just computational) security — a future cryptanalytic break of the commitment scheme does not retroactively compromise existing users.
One person, many sessions, no link.
Proofs from the same user across two verifiers cannot be correlated using the proof artifacts alone. Cross-site identity tracking is excluded by construction, not by policy.
Tell us. We listen.
Coordinated disclosure to security@rebellion.systems. Optional PGP key in the docs. We respond within 24h, fix within 7d for criticals, and credit you in the release notes if you'd like. There's a bounty in production.