TOTP Verification

Audience: Studio administrators, editors, authors, and operators troubleshooting sign-in

ZeroPress Studio requires a time-based one-time password (TOTP) authenticator for every account. The same verification policy applies during initial installation, invitation acceptance, account recovery, TOTP replacement, sign-in, and protected account changes.

Fixed TOTP parameters

Studio uses the standard parameters included in its otpauth:// enrollment URI:

• HMAC-SHA-1
• six decimal digits
• a 30-second period

The authenticator and the device running it should use automatically synchronized time. Studio does not provide an option to change these parameters.

Adjacent time-step tolerance

For a verification request, the Worker calculates the current 30-second counter step and compares the submitted code with three steps:

1. the previous step;
2. the current step;
3. the next step.

This tolerance prevents an ordinary boundary crossing or a small clock difference from immediately rejecting a code. For example, a code valid at 59 seconds remains within the accepted window at 60 seconds and at 89 seconds, but is outside the window at 90 seconds.

The tolerance is based on counter steps, not on a guaranteed lifetime measured from when a person reads the code. A device clock more than one step away from the Worker can still produce an invalid code.

A counter step can succeed only once

Time tolerance does not make a code reusable. After a successful verification, Studio atomically records the matched counter step for that TOTP factor. A later request is accepted only when it matches a strictly newer step.

Consequently:

• resubmitting the same code is rejected, even while it is still displayed;
• a concurrent replay cannot produce a second successful verification;
• if a code from the next step is accepted because the authenticator clock is ahead, codes from the current or any older step are no longer accepted.

Studio intentionally returns the same invalid-MFA result for an incorrect, already-used, or out-of-window TOTP code. The response does not reveal which condition occurred.

Enrollment followed immediately by sign-in

The TOTP code submitted at the final step of initial installation, invitation acceptance, account recovery, or TOTP replacement is a real successful TOTP verification. Studio stores that matched step as already used when it commits the factor.

After installation or invitation acceptance, Studio sends the user to the sign-in screen. If the authenticator still displays the same 30-second code, submitting it at sign-in is rejected as a replay even though it remains inside the adjacent time window. Wait for the authenticator to display the next code, or use an unused recovery code when that sign-in flow offers one. Repeatedly submitting the original code cannot succeed.

This first-sign-in boundary is the result of step-level replay protection, not an immediate expiration when the displayed TOTP period changes.

Troubleshooting

When a current-looking code is rejected:

1. Do not retry a code that already completed enrollment or another Studio verification.
2. Wait for the next six-digit code and submit it once.
3. Confirm that the authenticator device uses automatic date and time.
4. Use one stored recovery code if the account must be accessed while TOTP time synchronization is being corrected.

An operator should not weaken the verification window or edit the stored counter directly as a troubleshooting shortcut. Use the documented Maintenance & Recovery account-recovery flow when the enrolled factor cannot be used.