Comparing Authentication Models
Understanding the differences between passwords, passkeys, and device-bound proofs
Not all passwordless solutions are created equal. Passkeys were a step forward from passwords, but they introduced new attack surfaces through cloud sync. Hawcx takes a fundamentally different approach. Here's how they compare on the things that actually matter.
The comparison
| Passwords | Passkeys | Hawcx | |
|---|---|---|---|
| What's stored on your server | Password hash | Public key | Nothing |
| What's on the user's device | Nothing (user remembers) | Long-lived private key | Ephemeral key material |
| Cloud sync | Via password managers | Via iCloud/Google | None, device-bound only |
| Phishing resistance | None | Resistant (origin-bound) | Impossible (nothing to phish) |
| Server breach impact | Hashes exposed, crackable | Public keys exposed | Nothing to expose |
| Cloud account compromise | Password manager breach | All passkeys accessible | Not applicable |
| Quantum threat | Hashes crackable faster | Long-lived keys harvestable | Ephemeral, nothing to harvest |
| Multi-device | Same password everywhere | Synced via cloud | Independent per-device enrollment |
| User experience | Type, remember, reset | Biometric prompt | Single tap |
| Developer effort | High | Medium-High (WebAuthn) | Low (SDK handles everything) |
| Compliance surface | Large (credential storage) | Medium (key management) | Minimal (no credentials stored) |
Where passwords fail
Passwords are the oldest and weakest model. Users reuse them. Servers store them (or hashes). Phishing sites collect them. Credential stuffing automates the attack at scale. Every year, billions of credentials appear in breach databases. The model is fundamentally broken.
Developer burden: Password reset flows, hashing pipelines, rate limiting, breach detection, forced rotation policies, MFA as a band-aid.
Where passkeys improve, and where they don't
Passkeys eliminate the phishing problem by binding authentication to the origin. That's a real improvement. But they introduce a new risk: cloud sync.
When a passkey syncs through iCloud Keychain or Google Password Manager, the security of that passkey is now the security of the user's Apple or Google account. A compromised cloud account means compromised passkeys for every service that user has registered.
Developer burden: WebAuthn implementation complexity, attestation handling, cross-platform inconsistencies, fallback flows for unsupported browsers.
Where Hawcx is different
Hawcx eliminates the stored credential entirely. There is no password hash on your server. There is no long-lived key on the device. There is no cloud sync. Authentication happens through a fresh zero-knowledge proof generated in secure hardware, verified once, and discarded.
The bottom line
Passwords put the secret on your server. Passkeys put the secret in the cloud. Hawcx keeps the secret on the device and proves it without revealing it. That's not an incremental improvement; it's a different architecture.
Developer burden: Install SDK. Configure. Ship. The SDK handles the state machine, the cryptography, and the device integration. Your backend exchanges an auth code for claims, the same OAuth pattern you already know.
Deep comparison: Hawcx vs FIDO2/WebAuthn
Both Hawcx and FIDO2 share the same cryptographic foundation, the Classical Sigma (Σ) protocol using Schnorr-family signatures. The difference is what's built around that foundation.
| Dimension | FIDO2 / WebAuthn | Hawcx |
|---|---|---|
| Verification depth | 1 tier (signature only) | 3 tiers (hash → symmetric → asymmetric) |
| Mutual authentication | Client auth only | Dual-AEAD mutual auth (client verifies server too) |
| Server credential storage | Public key in plaintext | Public key AES-256 encrypted |
| Server index storage | User handle (plaintext) | Double-hashed, quantum-resistant |
| Quantum: data at rest | Vulnerable (Shor's on plaintext public key) | Resistant (AES-256 + double-hash) |
| Passkey sharing risk | Exportable via AirDrop, cloud sync | Non-exportable, never leaves vault/enclave |
| Mobile key protection | Hardware-bound (Secure Enclave/TEE) | Hardware-bound + information-theoretic splitting |
| Web key protection | Platform authenticator | Web Crypto vault, private key never in JS memory |
| Server data integrity | Not verified by client | Client verifies via AEAD decryption |
| Cross-device sync | Vendor-walled cloud sync (iCloud/Google/Microsoft) | Re-registration via email OTP (vendor-neutral) |
| Browser implementation | Proprietary per vendor, inconsistent feature support | Uniform Web Crypto API across all browsers |
| Algorithm agility | Limited | Runtime capability detection with downgrade prevention |
Hawcx provides stronger security properties in the majority of these dimensions. FIDO2's primary advantage is browser-enforced origin binding for phishing resistance (operating below the JavaScript layer) and the institutional weight of the FIDO Alliance (Google, Apple, Microsoft). Hawcx addresses phishing through SDK-level domain binding in the signed challenge.