Web Security / Basic: web trust and identity contracts / Lesson 3

Authentication, enrollment, and recovery

Design identity verification and account recovery as one lifecycle while keeping authorization and secrets separate.

About 4 min readContent reviewed 2026-10-26

On this page

Lesson goals

Distinguish authentication assurance from permission.
Review enrollment, factors, recovery, and abuse-resistant usability.

State what successful authentication establishes

Authentication checks control of an authenticator under a service’s protocol; identity proofing and account authorization answer different questions. A signed-in user does not automatically own every record or have permission to change account recovery settings. Use a maintained framework or identity provider with a reviewed integration instead of assembling a login protocol from string comparisons. Define the consequences of account takeover and choose assurance accordingly. Enrollment, factor replacement, session creation, sensitive-action reauthentication, and retirement all influence the effective boundary. A strong login page can be undermined by a weak help-desk or recovery path.

Handle passwords and factors through approved mechanisms

Unique long passwords and approved password managers reduce reuse, while the service needs supported password hashing and credential-lifecycle controls. A fast general hash is not a stand-alone password-storage design. MFA methods have different resistance properties, and phishing-resistant protocols require correct verifier binding and recovery. Do not collect real passwords or codes in classroom checks. Rate limiting, error messages, and lockout policy must consider both abuse and legitimate users; an aggressive universal lockout can create availability harm. Review current scoped identity guidance rather than relying on arbitrary composition rules or an assumed fixed rotation interval.

Record the lifecycle without recording credentials

The fictional account record names responsibilities and review states, not passwords, keys, reset links, or tokens. It is a planning artifact and creates no account. A production design should define who can approve factor changes, how the user is notified, how old authenticators and sessions are handled, and what evidence supports recovery. Keep recovery messages and support channels resistant to impersonation. Security questions based on easily obtained personal facts should not be treated as strong proof. Review fallback methods because the weakest accepted recovery path can dominate the protection of an otherwise strong primary factor.

json A fictional authentication-lifecycle review

{
  "accountLabel": "synthetic-editor",
  "primaryMethodReview": "complete",
  "factorReplacementOwner": "identity-maintainer",
  "recoveryReview": "pending",
  "sessionRevocationPlan": "documented",
  "containsCredentials": false
}

The values are declared lab facts and do not validate a real identity provider. pending remains visible. The file contains no credential, creates no account, and sends no notification.

Keep recovery gaps visible in a local policy model

The pure review function checks declared completeness, not identity. It makes a recovery gap visible even when the primary method was reviewed. Changing a boolean in this example does not authenticate a user or provide proof that an actual recovery exercise succeeded. A real system needs trusted evidence, support ownership, and a policy for ambiguous cases. Protect resets against repeated attempts and invalid requests through supported mechanisms. Avoid giving different unauthenticated responses that unnecessarily reveal whether an account exists, while still providing useful authorized support and an accessible path for legitimate users.

python A complete offline lifecycle-gap check

def identity_review(primary_reviewed, recovery_reviewed, retirement_defined):
    if not primary_reviewed:
        return "review-primary"
    if not recovery_reviewed:
        return "review-recovery"
    if not retirement_defined:
        return "define-retirement"
    return "scheduled-lifecycle-review"

assert identity_review(True, False, True) == "review-recovery"

Runs on synthetic booleans only and makes no account or network call. The expected label is review-recovery. The final scheduled state would not certify authentication strength or replace an actual verification process.

Verify legitimate use and failure paths

Review registration, sign-in, recovery, factor change, logout, and account retirement with synthetic identities in an authorized test environment. Include expired and invalid recovery attempts, changed permissions, and notification failure without exposing real users. Ensure secrets are not written to logs, analytics, or support tickets. Server-side authentication establishes a trusted session context; every protected action still needs authorization. Record version, configuration, result, and limitations of the integration tested. A successful local decision function or a vendor feature label is not proof that the complete account lifecycle is secure.

Common errors and fixes

A signed-in user can change unrelated records

Why it happens: Authentication is used as a substitute for authorization.
How to fix it: Enforce resource and action policy independently.
Prevent it next time: Test both identity and permission boundaries.

Recovery bypasses the reviewed primary factor

Why it happens: Fallback assurance was excluded from design.
How to fix it: Review factor replacement and recovery evidence together.
Prevent it next time: Include recovery in lifecycle exercises.

Reset diagnostics expose secrets

Why it happens: Raw credentials or links are captured in ordinary logs.
How to fix it: Minimize exposure and follow the credential owner’s response process.
Prevent it next time: Review logging and support fields before deployment.

Check your understanding

1. A strong passkey login has a weak account-reset path. Which boundary needs review?

Show worked solution

The complete recovery and replacement lifecycle, including evidence, approvals, notifications, and old-session handling. The presence of one strong method does not establish protection when a weaker accepted path can replace it.

2. A local function returns scheduled-lifecycle-review. Can the service claim verified authentication assurance?