Accountless Dashboard Authentication

ClearDNS does not need an email/password account to prove that a browser is associated with a ClearDNS device. Instead, dashboard authentication uses the device's existing DNS relationship with ClearDNS as part of the proof. The resolver credential and the dashboard session remain separate security objects.

The problem#

A browser cookie alone cannot prove which ClearDNS policy a device is using. Likewise, knowing a Policy ID should not be enough to obtain dashboard control.

ClearDNS therefore creates a short-lived pending browser session and waits for a network event observed through the device's configured ClearDNS resolver path.

Simplified flow#

browser opens ClearDNS dashboard
        |
server creates short-lived pending challenge
        |
browser requests a challenge hostname
        |
operating system performs DNS lookup
        |
lookup arrives through the device's authenticated ClearDNS resolver path
        |
resolver knows the exact policy/member/device binding
        |
pending browser session is bound to that tuple
        |
browser receives a separately controlled dashboard session

The DNS request is useful because the resolver has already authenticated the device's Resolver Credential and resolved it to a valid binding. The browser therefore does not need to send a claimed Policy ID and ask the server to trust it.

What is being proven#

The mechanism proves a practical property:

this pending browser session is being used from an environment whose DNS request arrived through this currently valid ClearDNS device binding.

It does not attempt to prove a civil identity, email ownership or username. That is consistent with ClearDNS's Zero-Identity model.

Resolver possession does not unlock the Dashboard#

ClearDNS uses DNS-assisted proof to establish which operational policy, member and device a browser session belongs to. That proof establishes resolver possession.

Resolver possession does not complete Dashboard authorization. For an established member, the authenticated session must satisfy the server-resolved Dashboard security requirement before protected administration continues. Security PIN is the baseline credential; when MFA is enabled, MFA becomes the interactive factor. A previously trusted browser may satisfy the current factor without requiring it to be entered again when the server can positively validate the current security state.

The security requirement is enforced by server-side session authority, not by a cosmetic browser overlay. Reloading the page, opening a direct Dashboard URL, clearing browser storage or calling a protected API directly does not bypass the requirement. A session satisfies its security requirement only after successful server-side verification.

The satisfied factor belongs to the authenticated Dashboard session. Internal navigation does not repeatedly challenge the session while it remains valid. A fresh authenticated Dashboard session must satisfy the current security requirement according to the session lifecycle. The requirement may be satisfied interactively or through valid trusted-browser state where that feature applies.

Resolver credential and dashboard session are different objects#

Resolver Credential#

Used to associate encrypted DNS requests with a policy/member/device binding.

Dashboard session#

Used to authorize browser access to policy administration surfaces.

A resolver credential is not an all-purpose administrative password. The dashboard session has:

• a separate lifetime;
• separate revocation;
• CSRF protection;
• policy-binding checks;
• optional additional authentication controls;
• active-session enforcement.

The four-step security distinction#

Authentication#

Is the resolver possession proof authentic?

Binding#

Which policy, member and device does that proof represent?

Session establishment#

Which short-lived browser session is being associated with that operational identity?

Dashboard authorization#

Has that authenticated session satisfied its current Dashboard security requirement, and what role is it already authorized to exercise?

Passing one stage does not grant the next.

Exact tuple binding#

A successful dashboard session carries the policy/member/device relationship established during authentication. Authenticated API requests verify that relationship instead of treating a browser session as an unscoped global login.

This makes it possible to enforce rules such as:

• a session remains tied to the policy it was created for;
• changing the device to a different policy does not silently migrate the old session;
• a revoked or unavailable binding does not automatically remain authorized;
• one active dashboard session can be enforced at the configured scope.

Short-lived administration#

ClearDNS treats a browser administration session as temporary state. The operational policy and device binding outlive an individual browser session; the session can expire and be recreated from a device that can again prove its relationship through ClearDNS DNS. This is different from making a permanent browser cookie the root identity.

Revocation#

Because session state and device binding are separate, ClearDNS can invalidate browser authorization when the underlying relationship is no longer acceptable. Examples include:

• the session expires;
• the session is explicitly revoked;
• the underlying device/policy relationship is disabled;
• the session's policy scope no longer matches;
• an active-session rule supersedes the previous session.

The exact recovery and state transitions are implementation details and may evolve, but the security boundary remains: browser authorization is not granted solely from knowledge of a public-facing policy identifier.

Cross-policy migration protection#

A useful edge case is a device that changes which ClearDNS policy it uses while a dashboard tab remains open. ClearDNS retains the policy identity captured when the browser authenticated and compares it with the policy currently bound to the session. If the relationship has changed, the old session is revoked rather than silently granting control over a different policy.

This preserves a simple rule:

one authenticated dashboard session administers the policy it authenticated for.

Availability failures and authorization failures are also kept distinct: a temporarily unreachable authority is not treated as proof that a session is valid, and a definitively revoked session is not retried into validity.

CSRF and same-origin controls#

Accountless does not mean stateless or unprotected. Authenticated dashboard requests still apply web security controls: same-origin checks, CSRF validation, short-lived session state, revocation, role/permission checks, and anomaly/security telemetry. The absence of a username/password does not remove the normal requirements of browser security.

Optional stronger controls#

Users can enable additional administrative security, such as time-based one-time-password verification for dashboard access. Those controls are layered on top of the device-bound session model rather than redefining ClearDNS as an email/password account service.

What this model protects against#

Policy URL as login. Knowing a Policy ID is not the complete dashboard proof.

Permanent account cookie as identity. Browser state is separately limited and revocable.

Silent policy switching. A session is bound to the policy established at authentication.

DNS credential as universal admin secret. Resolver transport and browser administration use separate authorization boundaries.

What it does not prove#

The flow does not identify the human holding the device. That is deliberate. ClearDNS needs to know that a valid device/policy relationship is administering the policy; it does not need to learn the person's name or email address to do so.

Related technical references#

• Identity and Resolver Credentials
• Device and Member Enrollment
• Security Model