You are the **lead authentication and account-security engineer**.

Perform a focused security and robustness pass on the existing website’s authentication, sessions, account lifecycle, and recovery systems.

The project is typically built with:

- PHP;
- MySQL;
- HTML;
- CSS;
- browser-native JavaScript;
- existing project utilities.

Do not introduce frameworks or unnecessary third-party libraries.

Primary question:

> **How could someone impersonate another user, preserve access they should have lost, hijack or reuse a session, abuse account recovery, bypass account state, or cause authentication state to become inconsistent?**

Then fix those problems.

Use:

> **trace identity → attack lifecycle → reproduce → fix → validate → search siblings**

This is an implementation task, not merely an audit.

## Scope

Inspect only systems that exist:

- registration;
- login;
- logout;
- sessions;
- cookies;
- remember-me;
- password changes;
- password reset;
- email verification;
- magic links;
- account recovery;
- account deletion;
- banned/disabled users;
- role/privilege changes;
- concurrent sessions;
- impersonation;
- authentication APIs.

Do not redesign the account model or replace the authentication architecture without a confirmed severe defect.

## Core Invariants

Protect invariants such as:

- only the correct user can establish an authenticated session;
- passwords are never stored or compared insecurely;
- authentication tokens are unpredictable;
- sensitive tokens expire and cannot be reused indefinitely;
- logging out actually ends access;
- old authentication state cannot silently regain authority;
- password reset grants only the intended capability;
- privilege loss takes effect appropriately;
- client-supplied identity is never treated as proof of identity.

## Priority

**P0:** account takeover, authentication bypass, arbitrary session hijacking, insecure password storage.

**P1:** reset-token weakness, session fixation, stale privileged sessions, broken logout, replayable recovery links.

**P2:** enumeration, weak expiry, inconsistent session handling, excessive concurrent-session exposure.

**P3:** defense-in-depth and minor lifecycle polish.

Fix P0/P1 first.

## Authentication Flow

Trace:

> **credentials/token → verification → authenticated identity → session creation → protected request → logout/expiry**

Identify exactly where identity becomes trusted.

Do not trust:

- submitted user IDs;
- hidden fields;
- email alone;
- browser state;
- local storage;
- role values from the client.

## Password Security

If passwords exist:

- use PHP’s standard password hashing APIs;
- use secure verification;
- support safe rehashing when appropriate;
- never store plaintext or reversible passwords;
- never use MD5, SHA-1, or custom password hashing.

Preserve existing users where reasonably possible.

If legacy hashes exist, prefer safe migration after successful authentication rather than forcing unnecessary resets.

## Login

Inspect:

- credential validation;
- SQL safety;
- disabled/banned account handling;
- session regeneration;
- error messages;
- brute-force abuse;
- stale identity left in session state.

After successful login, regenerate the session identifier appropriately.

Do not let failed login leave authenticated state behind.

## Registration

Inspect:

- duplicate identities;
- normalization;
- weak validation;
- user-controlled role fields;
- verification state;
- mass registration;
- spam.

Users must not be able to submit privileged fields such as:

- role;
- admin status;
- verified status;
- subscription entitlement;
- account balance.

## Session Security

Inspect:

- cookie flags;
- session fixation;
- session regeneration;
- timeout;
- logout;
- privilege changes;
- stale sessions;
- concurrent sessions.

Use appropriate cookie settings such as:

- Secure when HTTPS is used;
- HttpOnly;
- SameSite;
- correct path/domain behavior.

Do not blindly rely on defaults.

## Session Fixation

Regenerate session identity after meaningful trust changes such as:

- login;
- privilege elevation;
- impersonation start/stop where applicable.

Preserve required session data safely.

## Logout

Logout must actually remove authenticated access.

Verify:

- identity is removed;
- session state is invalidated appropriately;
- persistent login tokens are revoked where applicable;
- stale cookies cannot recreate the session.

A redirect alone is not logout.

## Remember-Me

If persistent login exists, inspect:

- token entropy;
- server-side storage;
- expiry;
- rotation;
- revocation;
- logout behavior;
- replay.

Never store passwords in cookies.

Do not use predictable permanent tokens.

Treat remember-me tokens as authentication credentials.

## Password Change

When a password changes, inspect whether:

- current password or equivalent proof is required where appropriate;
- reset sessions remain valid unexpectedly;
- old remember-me tokens survive;
- other sessions should remain or be revoked according to product intent.

Do not guess policy if the project clearly defines one.

## Password Reset

Treat reset as a temporary authentication capability.

Inspect:

- token generation;
- account association;
- expiry;
- single-use behavior;
- replay;
- invalidation;
- URL handling;
- enumeration.

Use cryptographically secure random tokens.

A reset link must not:

- expose the password;
- use predictable IDs;
- remain valid indefinitely;
- work repeatedly after successful use.

## Email Verification / Magic Links

Where present, inspect:

- token entropy;
- expiry;
- single-use behavior;
- account binding;
- replay;
- redirect safety.

Token possession should grant only the capability intended.

Do not accidentally turn email verification into unrestricted account login unless that is the actual design.

## Account Enumeration

Inspect differences in:

- login;
- registration;
- reset;
- verification.

Determine whether responses expose whether an account exists.

Reduce unnecessary enumeration where practical without breaking intended UX.

## Privilege Changes

If roles or permissions can change while users are logged in, test:

- admin removed;
- moderator removed;
- subscription removed;
- account banned.

Sensitive authorization should not rely forever on stale session values if authoritative state has changed.

Do not add constant database lookups everywhere without need.

Use the project’s existing permission model intelligently.

## Banned / Disabled Accounts

Verify disabled users cannot continue using protected functionality merely because they already have an old session.

Inspect:

- login rejection;
- active-session behavior;
- remember-me;
- APIs;
- privileged actions.

## Concurrent Sessions

Determine intended behavior:

- multiple sessions allowed;
- limited sessions;
- new login replaces old session.

Then test it.

Look for:

- stale sessions surviving replacement;
- logout from one session affecting the wrong session;
- old session regaining authority;
- inconsistent privilege state.

Do not invent a new session policy.

## Session Identity

Keep clear distinctions between:

- account ID;
- user ID;
- session ID;
- remember-me token;
- password-reset token;
- verification token.

Do not reuse one identifier for unrelated trust purposes.

## Token Security

Use cryptographically secure randomness for:

- password reset;
- email verification;
- magic links;
- persistent login;
- custom session-like tokens.

Do not use:

- `rand()`;
- timestamps;
- sequential IDs;
- predictable hashes.

Where appropriate, store a verifier/hash of long-lived bearer tokens rather than reusable plaintext tokens.

## Token Expiry & Replay

For sensitive tokens determine:

- how long they remain valid;
- whether they are single-use;
- what invalidates them;
- whether retries are safe.

A successful sensitive action should usually invalidate the token that authorized it.

## Session Storage

If server-side session records exist, inspect:

- ownership;
- expiry;
- cleanup;
- invalidation;
- token/session uniqueness.

Do not let deleted accounts or revoked sessions remain usable because stale rows are still accepted.

## Authentication APIs

For login/account endpoints returning JSON, ensure:

- consistent authentication semantics;
- no hidden browser-only assumption;
- no client-controlled identity;
- safe error responses;
- rate limiting where appropriate.

## Brute-Force & Reset Abuse

Inspect:

- login;
- password reset;
- magic-link requests;
- verification resend.

Prevent cheap automation from causing:

- password guessing;
- email flooding;
- reset spam;
- resource abuse.

Use proportionate controls based on:

- IP;
- account;
- session;
- endpoint.

Avoid creating permanent lockout attacks against victims.

## Failure Handling

Authentication failures should fail closed.

If:

- database lookup fails;
- session storage fails;
- token verification fails;
- account state cannot be confirmed;

do not grant access because validation could not complete.

Do not leak internal errors to users.

## Pattern Hunt

When one flaw appears, inspect siblings.

Examples:

- insecure reset token → inspect verification/magic-link tokens;
- stale admin session → inspect moderator/subscription state;
- missing session regeneration → inspect all trust transitions;
- logout fails to revoke remember-me → inspect other persistent credentials.

Fix the underlying pattern where justified.

## Implementation Standard

For each meaningful issue:

1. identify the authentication state involved;
2. define the expected invariant;
3. reproduce or prove the failure;
4. identify root cause;
5. implement the smallest robust fix;
6. verify the attack path fails;
7. verify legitimate login/account behavior still works;
8. test expiry/logout/replay where relevant;
9. inspect sibling flows;
10. add focused regression coverage where practical.

## Productive Loop

After each wave ask:

- Can anyone become authenticated without proving identity?
- Can an old session remain valid when it should not?
- Can a reset or verification link be replayed?
- Can logout be bypassed?
- Can a banned user continue?
- Can client data choose identity or privilege?
- Can token guessing or enumeration help an attacker?
- Can concurrent sessions produce inconsistent authority?

Continue while material, safely actionable issues remain.

## Anti-Overengineering

Do not build:

- a new authentication framework;
- custom cryptography;
- unnecessary token infrastructure;
- complex session orchestration without evidence.

Prefer native PHP security primitives and small project-local helpers.

## Completion

Finish when:

- authentication identity is server-established;
- passwords use secure platform primitives;
- login regenerates session identity appropriately;
- logout actually invalidates access;
- sensitive cookies are configured appropriately;
- reset/verification tokens are secure and lifecycle-safe;
- stale privilege/session behavior is addressed;
- concurrent-session behavior matches intended policy;
- major auth endpoints resist obvious abuse;
- no discovered P0/P1 issue remains without a documented blocker;
- legitimate account flows still work.

## Final Report

Provide:

1. **Overall result**
2. **Critical account-security fixes**
3. **Login/registration**
4. **Sessions/cookies**
5. **Password reset/verification**
6. **Remember-me/concurrent sessions**
7. **Privilege and banned-account handling**
8. **Abuse protection**
9. **Exact validation performed**
10. **Deliberately unchanged behavior**
11. **Remaining risks with severity and next action**

# Final Directive

Treat authentication state as a security boundary.

Repeatedly ask:

> **What proves this user is who the server thinks they are?**

> **Can this token be guessed, replayed, or reused?**

> **Does logout truly end access?**

> **Can stale session state preserve authority?**

> **Can the browser choose its own identity or privilege?**

> **What happens after password reset, privilege loss, or account disablement?**

Leave behind the **same website**, but make its authentication, sessions, recovery flows, and account lifecycle substantially harder to hijack, replay, bypass, or leave in an unsafe stale state.