Technical Whitepaper

Security Architecture

A deep technical breakdown of the cryptographic primitives, zero-knowledge verification mechanisms, and edge hardening safeguards engineered into 0fa.site.

Published: October 2026 โ€ข RFC 6238 Compliant โ€ข Web Cryptography API (W3C)

1. Executive Overview: Zero-Knowledge Design

In conventional cloud services, user secrets are sent over the wire, stored in central databases, and processed by remote backend workers. This traditional paradigm creates a high-value central target for attackers.

0fa.site inverts this architecture. The application is delivered as static, pre-compiled assets through Cloudflare's Edge CDN. Once downloaded, all cryptographic verification, HMAC hashing, Base32 decoding, and dynamic countdown timers execute strictly within your local browser execution context.

โšก

Zero Network Secret Transmission

Your two-factor secret keys are never transmitted over HTTP requests, never written to server disks, and never logged in edge access records.

2. RFC 6238 TOTP Standard & W3C Web Cryptography

Our Time-Based One-Time Password algorithm adheres strictly to IETF RFC 6238 (and its predecessor RFC 4226 for HOTP):

  • Time Step Calculation: The current UNIX epoch timestamp in seconds is divided by the step interval (default: 30 seconds), producing an 8-byte counter value.
  • Hardware-Accelerated HMAC: Key derivation and message signing are performed using window.crypto.subtle.importKey and window.crypto.subtle.sign with HMAC-SHA1 (or SHA-256/SHA-512).
  • Dynamic Truncation: The final 4 bits of the HMAC hash determine the dynamic offset, extracting a 31-bit unsigned integer formatted into a 6-digit or 8-digit verification code.

3. URI Fragment Isolation (RFC 3986 Section 3.5)

When customer delivery links are formatted with a hash parameter (e.g. https://0fa.site/#t=SECRET_DATA):

"The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource... The fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a request being sent."
โ€” IETF RFC 3986

Because web browsers never include the fragment in the GET request path or Referer headers, intermediate proxies, Cloudflare edge servers, and network monitoring appliances have zero cryptographic access to the customer secret.

4. Client-Side AES-GCM-256 Zero-Knowledge Payloads

For merchant deliveries containing login email, password, and 2FA secrets together:

  • The payload is encrypted before link generation using authenticated AES-GCM-256 with a random 96-bit Initialization Vector (IV).
  • The encryption key is embedded only within the client-side URL fragment.
  • Decryption occurs entirely within the buyer's browser. Even if an adversary intercepts the link transitively, without the local fragment key the ciphertext is mathematically unreadable.

5. Cloudflare Worker KV Ephemeral Storage & Burn-After-Read

For ephemeral links generated via our Edge API:

6. Marketplace Anti-Ban Obfuscation

Marketplace platforms (GGsel, Plati, G2A, Digiseller) frequently enforce automated text scanners that flag or penalize plain text domain URLs sent in buyer order chats.

0fa.site solves this through neutral alphanumeric identifiers and URL formatting that bypass automated domain blacklist heuristics while remaining 100% accessible to buyers on desktop and mobile browsers.

7. HTTP Edge Security Headers

Every response dispatched by 0fa.site includes an enterprise-grade set of security headers:

  • Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • X-Content-Type-Options: nosniff
  • X-Frame-Options: SAMEORIGIN
  • Referrer-Policy: strict-origin-when-cross-origin
  • Permissions-Policy: clipboard-write=(self), camera=(self)

8. Responsible Vulnerability Disclosure Program

We welcome constructive reports from security researchers and developers. If you discover a security vulnerability or cryptographic flaw within 0fa.site:

๐Ÿ”

Security Contact

Email our security team at [email protected]. Please include reproducible steps, browser specifications, and relevant payload samples. We acknowledge reports within 24 hours.