new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Better Auth · Authentication · all subjects

two-factor

9 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Two-factor account lockout configuration

Two-factor verification now includes account-level lockout by default. An account locks for 15 minutes after 10 consecutive failed verifications across all factors (TOTP, email-OTP, and backup codes share one counter). Locked attempts return HTTP 429 with the ACCOUNT_TEMPORARILY_LOCKED error code. Configure it with twoFactor({ accountLockout: { enabled, maxFailedAttempts, durationSeconds } }). This feature requires a database migration that adds failedVerificationCount and lockedUntil columns to the twoFactor table.

Two-factor TOTP and backup code attempt limit per challenge

Two-factor verification now limits TOTP and backup code attempts to five wrong codes per sign-in challenge. Once the limit is reached the challenge is rejected with TOO_MANY_ATTEMPTS_REQUEST_NEW_CODE, and a new sign-in is required to try again.

Two-factor challenge prevents concurrent redemption

An expired two-factor sign-in challenge can no longer complete login with a valid TOTP, OTP, or backup code, and the same challenge can no longer create more than one session when verified concurrently.

Two-factor OTP prevents concurrent redemption

Submitting the same two-factor OTP from several requests at once can no longer sign in more than once or gain extra tries beyond the attempt limit.

2FA enforcement scope by sign-in method

2FA is challenged only on credential-based sign-in endpoints: `/sign-in/email`, `/sign-in/username`, and `/sign-in/phone-number`. Non-credential sign-in flows (magic link, email OTP, OAuth, SSO, passkey, SIWE, one-tap, phone-number OTP, device authorization, email-verification auto-sign-in) are not gated by a 2FA challenge by default. This matches the behavior shipped through v1.6.2. A broader enforcement scope with per-method opt-outs and alignment to NIST SP 800-63B-4 authenticator assurance levels is planned for a future minor release.

2FA sign-in redirect returns enabled methods

The 2FA sign-in redirect response includes `twoFactorMethods` array (e.g. `["totp", "otp"]`) so frontends can render the correct verification UI without guessing. TOTP is included only when the user has a verified TOTP secret and TOTP is not disabled in config. OTP is included when `otpOptions.sendOTP` is configured. Unverified TOTP enrollments are excluded from the methods list. The `onTwoFactorRedirect` client callback receives `twoFactorMethods` as a context parameter.

Two-factor TOTP verified column tracks enrollment status

A `verified` boolean column was added to the `twoFactor` table to track whether a TOTP secret has been confirmed by the user. On first-time enrollment, `enableTwoFactor` creates the row with `verified: false`. The row is promoted to `verified: true` only after `verifyTOTP` succeeds with a valid code. On re-enrollment, the new row preserves `verified: true`, so the user is never locked out of sign-in while rotating their TOTP secret. During sign-in, `verifyTOTP` rejects rows where `verified === false`, preventing abandoned enrollments from blocking authentication. Backup codes and OTP work as fallbacks during unfinished enrollment. Migration: the new column defaults to `true`, so existing `twoFactor` rows are treated as verified. `skipVerificationOnEnable: true` creates the row as `verified: true`.

Backup codes preserve configured storage format after verification

After using a backup code, remaining codes are now re-saved using the same `storeBackupCodes` strategy (plain, encrypted, or custom) configured by the user. Previously, codes were always re-encrypted with the built-in symmetric encryption, breaking subsequent verifications for plain or custom storage modes.

Passwordless users can manage two-factor authentication

Passwordless users are now allowed to enable, disable, and manage two-factor authentication methods.

Give your agent this brain