Introduction

Phishing-resistant biometric authentication for modern SaaS applications.

ZTXBAS Authenticator eliminates the biggest weakness in traditional multi-factor authentication: susceptibility to real-time phishing attacks. By cryptographically binding each authentication request to its origin, ZTXBAS ensures that even the most sophisticated phishing attempts fail.

The Problem with Traditional MFA

Traditional MFA methods—SMS codes, TOTP apps, push notifications—share a critical flaw: they authenticate the user, not the context.

REAL-TIME PHISHING ATTACK (Traditional MFA)
1. Attacker creates fake site: fake.yourapp.com
2. User visits fake site, enters credentials
3. Attacker proxies credentials to real yourapp.com
4. Real app sends MFA push to user's phone
5. User approves (it's a real push from real app!)
6. Attacker captures authenticated session
Result: Account compromised despite MFA

The user did everything right. The MFA was "working." But the attacker still wins because the authentication system has no way to know the request originated from a phishing site.

How ZTXBAS Stops Phishing

ZTXBAS implements cryptographic origin binding. Every authentication request is tied to the specific origin (domain) where it was initiated.

SAME ATTACK AGAINST ZTXBAS
1. Attacker creates fake site: fake.yourapp.com
2. User visits fake site, enters credentials
3. Attacker tries to create auth challenge...
POST /api/auth/challenge
json: "origin": "https://fake.yourapp.com"
4. ZTXBAS API responds:
403 UNREGISTERED_ORIGIN
"Origin not registered - possible phishing attempt"
5. User's phone receives nothing. Attack blocked.

The attacker cannot bypass this because:

• They can't use the real origin: The request comes from their server, not the legitimate domain
• They can't register their own origin: Only your client credentials can register origins
• They can't omit the origin: The API requires it
• They can't fake it: HMAC signatures prevent request tampering

What Users See

When a legitimate authentication request reaches the user's mobile device, ZTXBAS prominently displays the origin:

If the user is on a phishing site, the URL in their browser won't match the origin shown on their phone—a clear signal not to approve.

---

Security Architecture

HMAC Request Authentication

Every API request is authenticated using HMAC-SHA256 signatures. No bearer tokens that can be stolen and replayed.

Signature = HMAC-SHA256(
    key: client_secret,
    data: "{METHOD}|{URL}|{TIMESTAMP}|{NONCE}|{BODY}"
)

Security properties:

Component	Protection
Method + URL	Prevents signature reuse across endpoints
Timestamp	Rejects requests older than 5 minutes
Nonce	Prevents replay within the 5-minute window
Body	Detects any tampering with request content

Origin Registration

Origins must be pre-registered before they can initiate authentication:

# Register your production domain
POST /api/origins/register
{
  "origin": "https://app.yourcompany.com",
  "display_name": "Your Company"
}

Only registered origins can create authentication challenges. Attempts from unregistered origins are rejected and logged for security monitoring.

Challenge-Based Authentication

Instead of long-lived tokens, ZTXBAS uses short-lived challenges:

1. Challenge Created: 120-second TTL, bound to user + origin
2. Push to Device: Secure channel to mobile app
3. Biometric Verification: User approves with Face ID / fingerprint
4. Session Issued: Only after explicit user approval

Memory-Safe Architecture

The API server uses:

• Fixed-size buffers: Eliminates buffer overflow vulnerabilities
• Timing-safe comparisons: Prevents timing side-channel attacks

---

Defense in Depth

Layer	Protection
Transport	TLS 1.3 encryption
Authentication	Per-request HMAC signatures
Authorization	Client-specific origin registration
Anti-Replay	Timestamp + nonce validation
Anti-Phishing	Cryptographic origin binding
Rate Limiting	100 requests/minute per client

---

Ready to eliminate phishing?

Contact Sales