GhostPass: Why We Built Authentication Without Accounts

The average authentication system stores a username, a password hash, an email address, a phone number, a creation timestamp, a last-login timestamp, an IP log, a device fingerprint, a session history, and a profile object containing whatever personal data the service decided to collect. When that service is breached, and 61% of organizations experienced a credential-related breach in 2024 according to the Verizon DBIR, all of this data is exposed. GhostPass stores none of it.

GhostPass is not authentication made better. It is authentication made from different axioms. The system does not minimize the data it collects. It eliminates data collection as a concept. There is no user database. There are no accounts. There are no credentials stored on any server. There is a cryptographic signature, a hashed address, and an ephemeral session that ceases to exist when the user is done.

The Design Philosophy

GhostPass began with a question: what is the minimum information a server needs to authenticate a request? Not what information is conventionally collected. Not what information might be useful later. The absolute minimum.

The answer is one bit of knowledge: is this request authorized?

Not “who is making this request?” Not “where are they located?” Not “what device are they using?” Not “when did they last log in?” Just: is this request authorized?

Sign-In With Ethereum provides this bit of knowledge through cryptographic proof. The user signs a message. The server verifies the signature. The request is authorized. The server has learned that the requester controls a specific cryptographic key. It has learned nothing else.

GhostPass takes this principle further. Even the Ethereum address, which is technically the public key derivative that SIWE verification produces, is too much information to store. An Ethereum address can be linked to on-chain transaction history, ENS names, token balances, and DeFi positions. Storing it creates a liability. So GhostPass hashes it.

The Technical Architecture

The GhostPass authentication flow operates in five steps. Each step is designed to minimize data exposure and maximize ephemerality.

Step 1: Nonce Request

The client sends a GET request to /auth/nonce. The server generates a cryptographically random nonce, stores it in Cloudflare KV with a 5-minute TTL, and returns it to the client. The nonce prevents replay attacks and expires automatically. No user data is involved in this step.

Client → GET /auth/nonce
Server → { nonce: "a8f3k2m9x1...", expiresAt: "2026-03-08T10:05:00Z" }

The nonce is stored in KV, not in a database. KV is a globally distributed key-value store at the Cloudflare edge. The entry auto-deletes after 5 minutes. No cleanup process is needed. No garbage collection. No database table accumulating expired nonces. The infrastructure itself enforces ephemerality.

Step 2: SIWE Message Construction

The client constructs a SIWE message following the EIP-4361 specification. The message contains the domain, the nonce, the chain ID, an issuance timestamp, and an expiration timestamp. The client presents this message to the user’s wallet for signing.

stealthcloud.ai wants you to sign in with your Ethereum account:
0xUserWalletAddress

Manifesting Ghost Session

URI: https://stealthcloud.ai
Version: 1
Chain ID: 1
Nonce: a8f3k2m9x1...
Issued At: 2026-03-08T10:00:00Z
Expiration Time: 2026-03-08T10:05:00Z

The statement “Manifesting Ghost Session” follows the Stealth Cloud brand voice: “Manifest” rather than “Sign In.” The user sees exactly what they are signing. There are no hidden fields, no background data collection, no consent checkboxes.

Step 3: Signature Verification

The client sends the signed message to POST /auth/verify. The server performs three operations:

1. Nonce validation. Check that the nonce exists in KV and has not expired. If valid, delete it immediately (one-time use).
2. Signature verification. Perform ecrecover on the signed message to extract the Ethereum address. Verify it matches the address in the SIWE message.
3. Address hashing. Apply SHA-256 to the verified Ethereum address. This is a one-way operation. The hash cannot be reversed to derive the original address.

const addressHash = await crypto.subtle.digest(
  'SHA-256',
  new TextEncoder().encode(verifiedAddress)
);

The original Ethereum address is held in RAM for the duration of the verification operation (microseconds in a V8 isolate) and then dereferenced. It is never written to storage, never logged, never transmitted to any third party.

Step 4: JWT Issuance

The server creates a JWT containing exactly two claims:

{
  "sub": "sha256:a1b2c3d4e5f6...",
  "exp": 1709942400
}

sub is the SHA-256 hash of the wallet address. exp is the expiration timestamp, set to one hour from issuance. There is no email claim. No name claim. No iat (issued at) claim. No iss (issuer) claim beyond the domain. The JWT contains the absolute minimum information required to validate subsequent requests.

The JWT is set as an httpOnly, secure, sameSite: strict cookie. It cannot be read by client-side JavaScript (preventing XSS token theft). It is only sent over HTTPS (preventing network interception). It is only sent to the issuing domain (preventing CSRF token leakage).

Step 5: Session Usage and Destruction

Subsequent requests include the JWT cookie. The server validates the JWT signature and expiration. If valid, the request is authorized. The sub claim (address hash) is used only to scope ephemeral session state in Durable Objects, never to look up a user profile (there is no user profile).

When the session ends, whether by explicit logout (POST /auth/logout), token expiration, or tab close, the following occurs:

1. The JWT cookie is cleared
2. The Durable Object session state is deleted
3. Any client-side encryption keys are destroyed via crypto.subtle.destroyKey()
4. The DOM is cleared of any conversation content

There is nothing to recover. There is nothing to subpoena. There is nothing to breach.

What GhostPass Does Not Store

The absence of data is the feature. For clarity, here is an explicit list of what GhostPass does not store, at any layer, at any time:

• No email address. There is no email field. There is no email verification flow. There is no password reset email.
• No password. There is no password. There is no password hash. There is no password policy. There are no password breaches.
• No phone number. There is no SMS verification. There is no 2FA via phone. There is no SIM-swapping attack surface.
• No name. There is no first name field. There is no last name field. There is no display name derived from an identity provider.
• No profile. There is no profile object. There is no avatar. There are no preferences stored server-side.
• No IP address. Cloudflare Workers process requests at the edge. The Worker does not log the connecting IP. Cloudflare’s own access logs are configured with minimum retention.
• No device fingerprint. There is no user-agent logging. There is no canvas fingerprinting. There is no device ID.
• No session history. There is no log of past sessions. There is no “last logged in” timestamp. There is no login frequency metric.
• No wallet address. The wallet address is SHA-256 hashed immediately upon verification. The plaintext address is never stored. The hash is stored only in the JWT, which expires in one hour and is never persisted server-side.

Compare this to a standard authentication system built on a modern framework (Auth0, Firebase Auth, Supabase Auth), which stores all of the above by default, plus analytics metadata, plus integration-specific identifiers.

Threat Model Analysis

GhostPass is designed against specific threat models. Honest security analysis requires identifying what it protects against and what it does not.

Threats GhostPass Defends Against

Server-side data breach. If every server in Stealth Cloud’s infrastructure is compromised, the attacker obtains: currently active JWT tokens (valid for at most one hour), Durable Object session state (encrypted, ephemeral), and Cloudflare KV entries (nonces with 5-minute TTLs, address hashes with session-duration TTLs). There is no user database to exfiltrate. There are no credentials to steal. There are no profiles to sell on the dark web.

Compelled disclosure. If a government serves Stealth Cloud with a legal demand for user data, the response is factual: there is no user data. There are no accounts. There are no stored identifiers. There are no conversation logs. The zero-persistence architecture means there is nothing to produce, not because of policy but because of architecture.

Identity provider compromise. There is no identity provider. GhostPass does not use OAuth. There is no dependency on Google, Facebook, or Apple. A breach at any of these companies has zero impact on GhostPass users.

Credential stuffing and password spraying. There are no passwords. These attacks have no surface to attack.

Account takeover via social engineering. There is no account to take over. There is no support team to social-engineer. There is no “forgot password” flow to exploit. There is no email address to target for phishing.

Threats GhostPass Does Not Defend Against

Private key compromise. If a user’s wallet private key is stolen (through malware, physical access, or social engineering), the attacker can authenticate as the user. This is inherent to any wallet-based authentication system. The mitigation is the user’s key management practice (hardware wallets, secure storage). GhostPass cannot protect users from themselves.

Client-side attacks. If the user’s device is compromised (keylogger, screen capture, browser extension malware), the attacker can observe decrypted conversation content in the browser. GhostPass protects data in transit and at rest on the server. Client-side security is the user’s responsibility.

Wallet address correlation. If a user authenticates with the same wallet address across multiple services and that address has public on-chain activity, the services cannot directly correlate (each would have a different hash of the same address), but if any single service stores or leaks the plaintext address, on-chain analysis could link the identity. This is why we recommend using a dedicated wallet address with no on-chain history for GhostPass authentication.

Timing and traffic analysis. An observer with access to network metadata (ISP, Cloudflare itself) can see that a particular IP address connected to stealthcloud.ai at a particular time. GhostPass does not provide network-level anonymity. Users seeking that level of protection should use Tor or a VPN in conjunction with GhostPass.

Comparison to Traditional Authentication

Why Not Just Use OAuth and Delete the Data?

This is the most common pushback. “Just use Google OAuth and don’t store the data.” The argument sounds reasonable until you examine the architecture.

OAuth generates metadata at the identity provider that you do not control. Google logs every authentication event. You cannot delete Google’s logs. You cannot prevent Google from correlating the authentication across their services. You cannot comply with a GDPR deletion request for data that Google holds.

Even on your own server, “delete after use” requires trust in the deletion process, the infrastructure, the caching layers, the log aggregation pipelines, the error reporting tools, and every developer who might add a console.log(user) during debugging. “We delete it” is a policy. “We never have it” is architecture. Policies fail. Architecture endures.

GhostPass does not rely on a promise to delete data. It relies on the mathematical impossibility of storing data that was never received. The server never sees an email because there is no email field. The server never sees a name because there is no name field. The server never sees a plaintext wallet address because it is hashed in RAM before any storage operation.

The Role of Cloudflare Workers

GhostPass runs on Cloudflare Workers, which provide properties essential to the zero-knowledge architecture:

V8 isolate model. Each Worker invocation runs in an isolated V8 instance. There is no shared memory between invocations. When the invocation completes, the isolate’s memory is reclaimed. Variables holding sensitive data (the plaintext wallet address during verification) are automatically garbage-collected. There is no filesystem to write temporary files to. There is no swap space where memory could be paged to disk.

Edge execution. Workers run at over 300 Cloudflare data centers globally. Authentication requests are processed at the data center closest to the user, reducing latency to under 50ms for most users globally. The request never traverses a centralized server.

Zero egress for verification. SIWE signature verification (ecrecover) is a CPU-bound elliptic curve operation. It requires no network call to any external service. The entire authentication flow, from nonce generation to JWT issuance, can complete without a single outbound network request. This eliminates the metadata leakage that occurs when authentication systems call external identity providers.

KV for ephemeral state. Nonces and session references are stored in Cloudflare KV with TTLs. KV is eventually consistent and globally distributed, meaning that ephemeral state is available at the edge without centralized storage. When the TTL expires, the data is automatically purged across all edge locations.

The Future of GhostPass

GhostPass is the foundation of Stealth Cloud’s authentication layer, and it will evolve as the ecosystem matures:

Multi-chain support. CAIP-122 (chain-agnostic Sign-In With X) will enable authentication with wallets on Solana, Cosmos, and privacy chains like Monero and Zcash. The authentication principle remains identical: sign a message, verify the signature, hash the address. The underlying chain changes, but the zero-knowledge property is preserved.

Session keys. ERC-4337 smart account session keys will enable delegated authentication, where a single wallet signature authorizes a session key that handles subsequent requests. This reduces the number of wallet interactions from one per session to one per delegation period, improving UX without weakening the security model.

Verifiable credential integration. GhostPass could accept zero-knowledge proofs derived from verifiable credentials as an optional authentication enhancement. “This wallet holder has a valid credential from issuer X” without revealing the wallet address, the holder’s identity, or the credential’s contents. This enables SSI-compatible authentication that remains zero-knowledge.

Passkey integration. WebAuthn passkeys stored in device secure enclaves provide a path to wallet-quality authentication without requiring users to manage browser extension wallets. A passkey-based GhostPass would authenticate with a biometric (fingerprint, face), derive a cryptographic signature, and the server would verify it without ever learning the biometric data, the device identity, or any personal information.

The Stealth Cloud Perspective

GhostPass exists because we asked a question that most authentication systems never ask: what if the server knew nothing about its users? Not as a policy aspiration, but as a mathematical constraint. The answer is GhostPass: authentication that proves authorization without producing identity, sessions that exist in RAM and nowhere else, and an architecture where a total infrastructure breach exposes nothing, because there is nothing to expose.