Sign-in and two-factor authentication

Your Tissue account is one identity across the dashboard, the ribo CLI, and the MCP server. This page covers the password, two-factor authentication, recovery codes, and what happens when you sign out other devices.

Everything here lives in the dashboard under Account → Security.

Your password

A password must be at least 8 characters, and it is checked against a public corpus of breached passwords before it is accepted — at sign-up, at password reset, and at password change. A match is refused with "That password has appeared in a public breach. Choose a different one."

The check uses the range API at api.pwnedpasswords.com: only the first five characters of the SHA-1 hash of the password leave the platform, and the full hash is compared locally against the returned list. If the lookup fails or times out after 5 seconds, the password is allowed. Failing closed would block the exact action a breach notice asks a person to take.

Changing your password signs out every other device. The browser you changed it in stays signed in; every other browser session and every ribo login on the account ends. See signing out other devices for the timing.

Two-factor authentication

Two-factor authentication adds a six-digit code from an authenticator app after your password. Tissue uses standard TOTP: a 30-second step, six digits, and a shared secret you scan once.

Turning it on

1. Account → Security → Set up two-factor.
2. Scan the QR code with an authenticator app, or type the secret shown beside it if the camera is not an option.
3. Enter the current six-digit code to confirm.

Enrolment is not live until step 3 succeeds. An unconfirmed enrolment is discarded after 10 minutes, so a QR code left open on a screen does not stay usable.

Codes are accepted for the current 30-second step and one step either side, which covers a clock that is up to 30 seconds out. A code that has been used cannot be used a second time, even inside its window.

Signing in with it

The sign-in page asks for the code after the password. The challenge is valid for 5 minutes and allows 5 attempts; a sixth attempt needs a fresh sign-in. Your password alone sets no cookie.

Turning it off

Turning two-factor off asks for your password and a current code or a recovery code. Both are required: a stolen session cookie plus a phished password should not be enough to remove the factor.

What two-factor covers

This is the honest limit: two-factor authentication protects the dashboard sign-in form. The OAuth authorization page that ribo login and the MCP client open verifies your email and password and stops there.

Two other facts follow from how sessions are versioned:

• Turning two-factor on or off signs out every other session, including any ribo login on the account. The device you did it from stays signed in.
• An existing tok_ API token keeps working through all of it. API tokens are not tied to your sign-in state; they are revoked by deleting them (ribo token revoke <id>, or the API tokens page).

Recovery codes

Confirming two-factor enrolment produces 10 recovery codes, each shaped xxxxx-xxxxx, drawn from an alphabet with no i, l, o, 0, or 1 so a printed code cannot be misread. Store them somewhere other than the phone holding the authenticator app.

Codes are stored as SHA-256 hashes. They cannot be shown again — the screen that displays them is the only time they exist in readable form.

• A recovery code substitutes for the six-digit code at sign-in, and at the second-factor prompt on account closure.
• Each code works once. Using one signs out every other session, because a spent recovery code means the authenticator is presumed lost, and emails you the number of codes left.
• Regenerate recovery codes replaces all 10 with a fresh set and invalidates the old ones. It does not sign anything out.

If you lose both the authenticator app and the codes, no self-service path exists — contact support from the account's email address.

Signing out other devices

Account → Security → Sign out other devices ends every other browser session and every ribo login on the account. The device you clicked it from stays signed in. No password is asked for; the action is destructive to sessions only, and it is the thing a person reaches for in a hurry.

The timing is not instant everywhere. Signing out takes effect:

• immediately for the account area and the auth service, which reads the session counter directly, and
• within 15 seconds for the management API, the ribo CLI, and MCP clients, which read a cached copy of that counter and refresh it on a 15-second cycle across both edges.

So a ribo deploy already in flight, or one started in the same second, can still succeed. Fifteen seconds later it cannot.

API tokens are not affected. A tok_ token survives a sign-out, a password change, and a two-factor change by design: killing a CI pipeline's deploy token is not what "sign out my other laptop" should mean. Revoke tokens on the API tokens page or with ribo token revoke <id>.

Everything that moves the session counter, and therefore ends other sessions:

A dashboard session cookie lasts 24 hours; a ribo login credential lasts 30 days. Both carry the session counter, so both answer to the table above.

New sign-in notices

A sign-in from a device and network the account has not been seen on for 30 days sends an email with the IP address, the user agent, and the time. Devices in regular use are announced once, not monthly: the record is refreshed on every sign-in, so the 30-day window rolls forward.

The notice is preference-gated — see email preferences. Security notices for password changes, email changes, two-factor changes, and scheduled closures are sent regardless of preferences.

See also

• Your account profile: changing your email address and notification preferences
• Members and roles: who can do what on a shared account
• Account activity: the audit feed of mutating actions
• Accounts & Profiles: which account the CLI acts on