> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tuturuuu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Shared-secret password reset

> Required reset and owner recovery for retired Nova challenge and Meet guest credentials.

## Scope and default

Under the 25 October 2026 reset policy, every non-empty stored hash outside the
accepted scrypt format is a reset marker, including older short digests and malformed
scrypt values. These markers are never verified or upgraded using a submitted
password. The shared verifier returns `resetRequired: true` and `valid: false`,
without computing a SHA-256 digest. All new credentials use scrypt. Empty or
absent values are not reset markers.

This decision covers two credential domains and three app surfaces:

| Credential | Storage | Surfaces | Authorized recovery owner |
| - | - | - | - |
| Nova challenge password | `private.nova_challenges.password_hash` | Nova challenge start/resume and access grants | An assigned challenge manager or a role already permitted to manage all challenges |
| Meet guest password | `public.meet_together_guests.password_hash` | Meet native plans and the shared Web Meet plan UI, including guest mutations | The signed-in creator of that plan |

These are application shared secrets, not Supabase account passwords. Account
sign-in, email password reset, account sessions and MFA are unchanged. Meet guests
have no email recovery identity. Anonymous callers cannot reset a guest by name.

The existing hash format is the durable marker. No extra flag, schema migration,
bulk database update, automatic password clearing or record deletion is needed.
The actual number of legacy rows cannot be inferred from source. Potential scope
is every row with an unsupported non-empty hash in these two tables, with no finite
row-count bound in the schema; zero provider account-password rows are affected. No production query is
part of this decision.

## User recovery

Nova returns HTTP 409 with `code: PASSWORD_RESET_REQUIRED`; the confirmation form
shows the reset instruction in English or Vietnamese instead of “wrong password”.
A challenge manager opens **Edit challenge**, enters a new password under the
password setting, and saves. The existing authorized update writes scrypt. The
manager shares the new challenge password privately with participants. Managers
may instead deliberately remove challenge password protection using the existing
setting; normal unprotected-challenge access rules then apply.

Meet returns the same reset code and a localized instruction to contact the plan
creator. On the plan page, the signed-in creator uses **Reset a guest password**,
enters the guest name exactly as used to sign in and sets a new password. For a workspace plan, the creator must also retain the same MEMBER access
required to open the plan. The server rechecks plan ownership,
scopes the guest to that plan, and conditionally replaces only the legacy hash.
The creator chooses the guest's new password and can therefore sign in as that guest.
A concurrent credential change is never overwritten. Current scrypt credentials
are outside this recovery action. The guest signs in with the new password;
reset itself issues no session. Guest identity, availability and votes are kept.

If a Meet plan has no available authenticated creator, the legacy guest identity
stays blocked. A participant can use their Tuturuuu account or a new guest name. New passwordless guests still use scrypt for the empty password;
legacy passwordless identities cannot be distinguished safely and also require reset.
Existing data is retained; there is no unauthenticated takeover or email reset.

## Existing grants and rollout

Nova challenge grants and Meet guest tokens now use versioned purpose names.
Tokens issued under the retired verifier are rejected, including after the owner
resets a row. This deliberately requires one-time password re-entry for holders
of older grants, including scrypt credentials; their existing scrypt password
continues to work. Account sessions and MFA are not revoked. The new policy also
checks the backing row so even a correctly signed new token cannot authorize a
row that still requires reset.

Ship the shared verifier, owner recovery, localized forms and token consumers
across Web, Nova and Meet together. Require exact-commit app CI/build and independent
security review. Do not roll back to the former verifier while legacy rows remain.

## Regression evidence

* `packages/utils/src/__tests__/legacy-password-reset.test.ts`: long/short legacy and malformed-hash rejection,
  no SHA-256 computation or legacy writer, valid scrypt, retired-token rejection.
* `apps/nova/src/app/api/auth/challenges/verify-password/route.test.ts`: reset
  response without a grant, valid scrypt, wrong-password and user-binding controls.
* `apps/nova/src/lib/challenge-password-error.test.ts` and the shared Meet
  `plan-login-reset.test.tsx`: actual English/Vietnamese reset copy.
* `packages/apis/src/meet/guest-password-reset.test.ts`: creator-only recovery,
  foreign-plan denial, conditional update, data retention and held-row session denial.
* Meet native `guest-password-reset.test.ts` and `legacy-action-ports.test.ts`:
  app-session actor injection, argument validation and unsigned-request rejection.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.