mino.mobi / poll / security evaluation

1. Timing Oracle on Credential Verification

packages/shared/src/crypto/index.ts:159–166

The timingSafeEqual function short-circuits on length mismatch with an early return, leaking information about the expected signature length through response timing. An attacker can measure response times to learn the length of valid HMAC signatures, reducing the search space for brute-force attacks.

function timingSafeEqual(a: string, b: string): boolean {
  if (a.length !== b.length) return false;  // ← timing leak
  let diff = 0;
  for (let i = 0; i < a.length; i++) {
    diff |= a.charCodeAt(i) ^ b.charCodeAt(i);
  }
  return diff === 0;
}

Fix: Pad both strings to equal length before comparison, or use a constant-time comparison that always iterates over the longer of the two strings.

2. DID Impersonation in Mock Mode

apps/api/src/routes/auth.ts:58–70

In mock mode, the DID is derived deterministically from the user-supplied handle parameter: did:plc:mock${handle.replace(/\./g, '')}. Any caller can forge arbitrary DIDs by choosing the right handle string. This allows impersonating the poll host and gaining admin access to any poll. If mock mode leaks to production (the ATPROTO_MOCK_MODE env var defaults to "true" in wrangler.toml), the entire auth system is bypassed.

Fix: Default ATPROTO_MOCK_MODE to "false". Add a startup check that panics if mock mode is enabled in a production environment. Never derive DIDs from user input.

3. Silent Signing Key Fallback

apps/api/src/routes/polls.ts:86–87

If the CREDENTIAL_SIGNING_KEY environment variable is not set, the code silently falls back to crypto.randomUUID() as the HMAC key. This means each poll creation generates a different ephemeral key. Credentials issued under one key cannot be verified under another. The signing key is passed to the Durable Object at initialization, so if the DO restarts and the key was ephemeral, all outstanding credentials become unverifiable.

const signingKey = env.CREDENTIAL_SIGNING_KEY || crypto.randomUUID();

Fix: Fail loudly if CREDENTIAL_SIGNING_KEY is not set. Never fall back to random keys for cryptographic operations.

4. Durable Object State Loss Breaks All Guarantees

apps/api/src/durable-objects/poll-coordinator.ts:53–75

The DO stores nullifiers, consumedDids, and lastAuditHash in its storage. If the DO's storage is lost or evicted, these sets reinitialize as empty. This means:

• Previously consumed DIDs can request new credentials (double voting)
• Previously spent nullifiers are accepted again (ballot replay)
• The audit hash chain restarts from zeros (tamper evidence broken)

D1 has the permanent records, but there is no recovery path that rebuilds DO state from D1. The DO simply starts fresh with empty sets.

Fix: On cold start, rebuild consumedDids and nullifiers sets from D1's eligibility and ballots tables. Recover lastAuditHash from the most recent audit_events row.

5. No Recovery Path for Serialized State

apps/api/src/durable-objects/poll-coordinator.ts:77–83

Related to finding #4: the saveState method serializes Sets to Durable Object storage, but the loadState method tries to reconstruct Sets from the stored data. However, JavaScript Sets serialize as objects (not arrays) in structured clone, and the restoration code does new Set(stored.nullifiers) which, if stored.nullifiers survived serialization as a Set, would produce a Set containing one Set — not the original values.

stored.nullifiers = new Set(stored.nullifiers);
stored.consumedDids = new Set(stored.consumedDids);

Fix: Convert Sets to arrays before storage ([...set]) and reconstruct from arrays on load. Or use DO's built-in structured clone which handles Sets correctly in newer runtimes — but test explicitly.

6. No Ballot Submission Time Window Check

apps/api/src/durable-objects/poll-coordinator.ts:286–293

The ballot submission handler checks state.poll.status !== 'open' but does not verify that the current time falls within opensAt...closesAt. The eligibility handler does check the time window, but the ballot endpoint does not — and since ballot submission is credential-based (no session), there is no guarantee the ballot is submitted during the authorized window. A credential issued at T=1 can be submitted at T=∞ as long as the poll status hasn't been manually changed.

Fix: Add new Date() > new Date(state.poll.closesAt) check in handleBallot.