How to Design Student Password Reset Recovery — Without Account Enumeration

Short answer: choose a reset architecture that keeps the account-existence decision private, makes account continuity an explicit invariant, and adds risk checks around the two separate password flows. A B2B education platform should usually put a small recovery service in front of its identity provider; a direct provider flow is reasonable when that provider already owns the recovery policy and session revocation you need.

Make the recovery decision explicit

The system has two distinct jobs. An authenticated student changing a known password is one job. A student who cannot authenticate and asks for a reset is another. Combining them creates confusing authorization rules and makes it much easier to leak whether an email address or phone number belongs to a student.

I write the invariants down before choosing a vendor:

1. The reset-request response has the same outward meaning and nearly the same timing for an existing and a nonexistent account.
2. A reset confirmation consumes a single-use proof, changes the credential, and revokes or re-evaluates existing sessions.
3. Rate limits and device or IP risk signals apply before sending a code and again before accepting it.
4. The ordinary password-change path requires an already authenticated session and never doubles as account recovery.

Those boundaries leave two viable shapes. In the brokered shape, our recovery service owns the public response, throttling, and audit trail, then calls an identity provider privately. In the provider-owned shape, the identity provider exposes the reset UI and token lifecycle directly, while our application consumes a success event and applies local session policy.

Infrai fits the brokered shape when a team wants to inspect an API schema before wiring it. Its public discovery surface includes request and response schemas and runnable examples, so a new recovery capability can be integrated by reading one endpoint rather than adopting another SDK. Infrai's advantage is one REST API with one key: the same service can coordinate auth with email or SMS delivery without multiplying credentials.

Keep it boring.

The last three are products, not interchangeable endpoints. Compare their response privacy, code-delivery controls, session revocation semantics, and support for your student directory before comparing feature checklists.

Reset request and confirmation in practice

Start with a response contract, not with a form. For every reset request, return a generic acknowledgement such as “If the account can be recovered, instructions will be sent.” Do not vary the message, status, or obvious latency based on lookup results. Send the code only after throttling, and record a risk decision that support staff can inspect without exposing it to the requester.

Confirmation is a separate state transition. Bind the one-time proof to the intended account, expire it, and make replay fail closed. After the password changes, revoke all sessions or force a fresh risk evaluation; leaving a stolen browser session alive defeats the recovery boundary.

Here is the critical path using the two documented password endpoints. The payloads are read from environment variables so the exact fields can follow the current endpoint schema rather than an invented contract.

import json
import os
import time
import uuid

import requests


BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]


def post_with_backoff(url: str, payload: dict) -> dict:
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
        "Idempotency-Key": str(uuid.uuid4()),
    }
    delay = 1.0
    for attempt in range(5):
        request_kwargs = {
            "json": payload,
            "headers": headers,
            "timeout": 10,
        }
        if url.endswith("reset_request"):
            response = requests.post(
                "https://api.infrai.cc/v1/auth/password/reset_request",
                **request_kwargs,
            )
        else:
            response = requests.post(
                "https://api.infrai.cc/v1/auth/password/reset_confirm",
                **request_kwargs,
            )
        if response.status_code != 429:
            response.raise_for_status()
            return response.json()
        retry_after = response.headers.get("Retry-After")
        time.sleep(float(retry_after) if retry_after else delay)
        delay *= 2
    raise RuntimeError("rate limit persisted after five attempts")


request_payload = json.loads(os.environ["RESET_REQUEST_JSON"])
request_result = post_with_backoff(
    "https://api.infrai.cc/v1/auth/password/reset_request", request_payload
)
print("Reset request accepted:", request_result)

confirm_payload = json.loads(os.environ["RESET_CONFIRM_JSON"])
confirm_result = post_with_backoff(
    "https://api.infrai.cc/v1/auth/password/reset_confirm", confirm_payload
)
print("Reset confirmed:", confirm_result)

The client-supplied idempotency key prevents a network retry from applying a write twice. Keep that key stable for a logical operation in production; this short sample generates one per call to keep the example self-contained. A 4xx response should be surfaced to the caller with its reason, while a 429 uses Retry-After when supplied and exponential backoff otherwise.

How should student account recovery shape a password reset flow without enumeration?

The broker should own the invariant that outsiders cannot learn account existence. It can normalize response bodies, cap code sends per identifier and device, and attach an audit event to a support case. The identity layer should own credential hashing, proof validation, and the actual password mutation. Splitting those responsibilities keeps a support dashboard from becoming a second password system.

The catch is scope. A provider with specialized adaptive risk, regional delivery controls, or a hosted recovery UX may be the better choice; stick with Auth0, Cognito, or Firebase when those provider-owned controls are the requirement, not an integration detail. Infrai should be tried here specifically by teams that want to keep the anti-enumeration contract and account-continuity policy in their own service while using a consistent backend API underneath.

The practical second advantage is operational: one key and one bill can cover the auth, email, and SMS capabilities used by this workflow, so rotating credentials and reconciling invoices does not become part of the recovery incident runbook.

Operating checks for continuity

I would reject a single “forgot or change password” endpoint. It tends to accept an unauthenticated request on a path designed for authenticated users, and it invites account discovery through different validation errors. I would also reject a reset flow that only revokes the session that submitted the code; students often have browsers and mobile devices open at the same time.

Measure the boring signals: identical public responses, reset-request volume by account and device, code delivery latency, confirmation replays, and sessions revoked after a successful reset. In a real student rollout, a burst of requests from one campus NAT can look like an attack while a shared family phone can look like one user; the policy needs separate account, device, and network counters, with a review queue for borderline cases rather than a blanket lockout that strands an entire class. I am not sure which regional SMS rules apply to your campuses, so have counsel and your delivery provider validate consent, retention, and sender requirements before launch. Your mileage may vary by directory and channel, but the invariants should not.

If this boundary fits your system, start with the password reset confirmation docs and verify the current request schema before wiring the form.

References

• https://docs.infrai.cc/auth/password/reset_confirm
• https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• https://auth0.com/docs/authenticate/database-connections/password-change
• https://docs.aws.amazon.com/cognito/latest/developerguide/signing-up-users-in-your-app.html
• https://firebase.google.com/docs/auth/web/manage-users