Authentication

Every Studio account must enroll a TOTP authenticator before gaining normal access. MFA cannot be disabled. A registered Passkey provides another sign-in method; Studio never falls back to password-only access.

Sign-in Methods

Method	Required verification
Password and authenticator	Password followed by a current TOTP code
Password and registered WebAuthn credential	Password followed by the registered credential at the MFA step
Sign in with a Passkey	A discoverable credential for the current hostname, with authenticator user verification required

Mandatory TOTP enrollment does not mean every later login must enter a TOTP code. The direct Passkey flow verifies the credential and the authenticator’s user-verification result before issuing a Studio session. See Passkeys for hostname scope and credential information.

Password Policy

New passwords must be at least 15 and at most 256 characters. Length is measured in UTF-16 code units, so some Unicode characters occupy more than one unit. The policy also rejects account-related values and passwords in Studio’s bundled common-password list.

Account checks use the email address and display name, including normalized matches and sufficiently long identity fragments. The acceptance policy does not require a fixed mixture of uppercase, lowercase, digits, and symbols. The strength indicator helps choose a password; the server applies the acceptance policy.

Passwords are stored as salted Argon2id hashes. TOTP secrets and external service credentials instead require reversible encryption under keys derived from STUDIO_AUTH_SECRET; that Worker Secret is not a user password.

Breach Checks

In deployed Workers, Studio checks HIBP Pwned Passwords in addition to its bundled list. It hashes the password in the Worker and sends only the first five hexadecimal SHA-1 characters to the range API, with response padding. The password and full digest are not sent. SHA-1 here is used for the lookup, not for storing the password.

Local development, tests, and local preview use the bundled list. If the remote breach service is unavailable, Studio reports the reduced check and allows a password that passes its local policy. A positive breach match is rejected.

Sensitive Account Changes

Password changes, MFA management, and protected account-management operations require reauthentication. Studio checks the current password and asks for an MFA step-up when the last accepted MFA verification is no longer fresh. The freshness window is five minutes; it does not extend the session’s absolute lifetime.

Authorization is scoped to the requested action and, where applicable, its target account or credential. A successful unrelated action does not grant general administrative access.

Attempt Limits

Cloudflare’s configured native authentication limiter runs before Studio’s own D1-backed limits:

Budget	Limit
Password sign-in per normalized email	5 attempts in 2 minutes, including unknown accounts
Sign-in per client IP	20 attempts in 15 minutes, shared by password sign-in and direct Passkey options
Enrolled TOTP verification per account	10 attempts in 5 minutes, shared by sign-in and protected changes

Windows begin with the first attempt. Accepted, incorrect, and replayed TOTP codes consume the TOTP budget; success does not reset it. Rejected requests do not extend a window. Changing IP does not reset an account’s TOTP budget.

Rate-limit responses include Retry-After. Wait until the window ends, and restart sign-in if its continuation has expired. A separately permitted Passkey login remains available. A failed rate-limit database prevents authentication rather than bypassing the checks.

The client IP policy also applies to authentication. Counters store purpose-separated HMAC digests of their email or IP subject rather than those raw values.

For authenticator timing and replay behavior, read TOTP Verification. For lost factors, follow MFA Recovery; Studio does not issue recovery codes.