Accountless Dashboard Authentication

ClearDNS uses Resolver-Verified Dashboard Access: the authenticated DNS relationship establishes the policy, member and device identity used for Dashboard authentication. The browser's initial policy association comes from DNS use with a valid ClearDNS resolver configuration. Supplying a Policy ID, an email address or an account password does not establish that relationship.

This makes the configured DNS relationship part of the Dashboard's access control. ClearDNS separately checks the current binding and applies the member's security and role requirements before granting Dashboard authority. The resolver credential and the Dashboard session remain separate security objects.

The problem#

A public policy identifier tells a service which policy is being requested. It does not prove authority over that policy.

ClearDNS establishes the browser's initial policy/member/device association through a DNS request authenticated by its resolver. The Dashboard uses that server-established identity and validates the corresponding binding before completing login. It does not accept a browser's claimed Policy ID as proof of possession.

There is no alternative ClearDNS email/password login for administering the policy. This removes a reusable account-password credential, email/password credential stuffing and an email-based password-reset dependency from the Dashboard's access model.

Simplified flow#

1. The browser starts Dashboard authentication.
2. A DNS request through the configured ClearDNS resolver relationship establishes the pending session's policy/member/device identity.
3. The Dashboard validates the current binding and resolves the member's security requirement.
4. The browser receives a temporary Dashboard session after the applicable requirements are satisfied; administration remains limited by role and policy scope.

For established members, the security requirement is PIN or MFA, with applicable trusted-browser handling. The first-use rule is described below.

The resolver authenticates the Resolver Credential; the Dashboard controls browser authorization. The exact challenge and session-establishment mechanics are private implementation details.

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#

Resolver proof establishes which operational policy, member and device the pending browser session represents. Dashboard authorization additionally depends on the current binding, the member's security state and their role.

Established members. Security PIN is the baseline credential. When MFA is enabled, MFA becomes the interactive factor. A previously trusted browser can satisfy an applicable requirement only when the server positively validates its trust and current security state. Trusted-browser state does not independently select or establish the policy identity.

First use. A member who has never enrolled a Security PIN can receive one non-extendable initial Dashboard session after resolver proof and binding validation. This session carries normal Dashboard authority within the member's role. PIN enrollment is required before subsequent normal Dashboard access. The separate PIN-setup credential authorizes enrollment only and cannot serve protected Dashboard APIs.

The security requirement is enforced on the server. A pending authentication attempt, a resolver credential or an unfinished PIN-setup flow is not an authorized Dashboard session. Internal navigation does not repeatedly challenge a session whose applicable security requirement remains satisfied.

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 browser administration as temporary state. The policy and device binding outlive an individual Dashboard session; browser authority has its own expiry, revocation and security requirements.

Initial policy association is established through the resolver. Session continuation and reauthentication can use previously established server-side state within the permitted lifecycle. Resolver verification is therefore not a claim that every page visit requires a new DNS request or that removing a local DNS profile instantly revokes every already-issued browser session. Protected Dashboard requests continue to enforce session validity, current binding authority and policy scope.

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#

Email/password credential stuffing. ClearDNS has no reusable account email/password pair for this attack to target.

Mailbox-based password reset. ClearDNS does not give an email mailbox password-reset authority over the DNS policy.

Policy URL as login. Knowledge of a Policy ID does not establish resolver possession or Dashboard authority.

Silent policy switching. An authenticated Dashboard session remains scoped to the policy it authenticated for.

Resolver configuration as sole authority for established administration. An established member's PIN or MFA requirement remains separate from resolver possession. Browser-session expiry, revocation and role controls also remain in force.

What it does not prove#

The resolver authenticates the presented configuration and the service validates its operational binding. This does not attest that the request came from the original physical device or prove the identity of the person using it.

An exact copy of a usable resolver configuration can represent the same binding while that binding remains authorized. Protecting device configuration and browser sessions remains part of the security model. The separate administration requirement for established members and the first-use rule above define the Dashboard authority available after resolver proof.

Policy Recovery has its own owner-verification requirements. Successful recovery authorizes provisioning a device into the recovered policy; the recovery grant is not a Dashboard session.

Related technical references#

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