What does this PR do?

Adds a password-pwned project policy that checks passwords against the Have I Been Pwned breach database, rejecting a breached password with a new password_pwned error (HTTP 400). Users carry a passwordPwned flag recording the outcome of the last check.

The policy is enabled by default per project, but the server asks nobody until it is configured. _APP_PWNED_PASSWORDS_DSN defaults to none://localhost, which reports every password as safe; point it at a breach service and projects reject breached passwords out of the box. Checking passwords on sign-in is opt-in.

• Policy surface: PATCH /v1/project/policies/password-pwned, entries in list and get policy, policyPasswordPwned response model, SDK method updatePasswordPwnedPolicy. Stored as auths.passwordPwned. All update params are optional and omitted ones keep their value, like password-strength.

• Options, three in total

  • enabled (default true): reject a password found in any known breach when it is set or changed.
  • sessions (default false): also check the password when a session is created, recording the outcome on the user.
  • users (default false): block a checked sign-in with user_password_reset_required (412) until the password is reset. Only applies when sessions is on.

  Lookups are server configured, so a project cannot redirect the check at its own service. When the breach service cannot be reached the request fails with general_pwned_passwords_unavailable (503) rather than silently passing a breached password.

• Validators. Appwrite\Auth\Validator\PasswordPwned is abstract with one subclass per service, the same shape as OAuth2 and its providers. A single _APP_PWNED_PASSWORDS_DSN picks the subclass by scheme, the way storage, logging and the database connections are already configured, and an unknown scheme fails loudly rather than falling back. The request resource hands back the right subclass, so call sites use isValid() exactly as they already do for PersonalData and PasswordHistory.

  DSN	Asks	What leaves the server
  hibp://localhost	Public Have I Been Pwned range API	First five characters of the SHA-1 hash, k-anonymity. Ranges cached per prefix for an hour. No detail is read from the DSN
  appwrite://SECRET@HOST[:PORT][/PATH][?tls=true]	An Appwrite Pwned service you run	The whole password, authenticated with SECRET as a Bearer token (the service's APPWRITE_PWNED_SECRET). Only appropriate on a network you control or behind TLS. The service answers from its own copy of the Have I Been Pwned corpus, so nothing about the password leaves that network
  none://localhost (default)	Nothing, answers in process	Nothing. Reports every password as safe, so the policy protects nothing until the server is pointed at a real service. The default, and the right choice for a server that must not or cannot reach a breach service, such as an air-gapped installation
  mock://localhost	Nothing, answers in process	Nothing. Reports a fixed list of passwords as breached so the suite can exercise the policy. Refused on a production server, where it would report every real password as safe

• User flag passwordPwned (nullable boolean, indexed) on the User and Account models: null until a password is checked, false when the last check was clean, true when it found a breach. Written on account and user creation, password updates, recovery, anonymous conversions, and checked sign-ins (recorded even when a forced reset blocks the sign-in). Setting a password with the policy off, clearing it, or importing a hash resets it to null; an outage leaves it untouched. Filterable in users list with equal, isNull, and isNotNull. Attribute and index are added by the V25 migration.

• Reading the policy. The validator carries no policy of its own. Each call site reads auths.passwordPwned from the project, the way the personal data and history checks already read theirs, so null on the user attribute comes from not asking rather than from a return value.

• Anonymous conversions: anonymous accounts setting their first password through the email or phone update endpoints now go through the same policies as account creation: strength, dictionary, personal data, pwned, and history. Existing passwords are only verified, never re-validated.

• Config _APP_PWNED_PASSWORDS_DSN (documented in variables.php, passed in docker-compose.yml), defaulting to none://localhost so a fresh or upgraded instance never calls out on its own.

• Testing without the real service: the repo .env sets mock://localhost, so the suite never reaches a breach service and the mock range route that used to live in app/controllers/mock.php is gone.

Notes for reviewers

• Enabled by default reaches existing projects, but checks nothing until configured. A project that has never configured the policy inherits enabled: true, while the server's default none://localhost answers every check as clean, so an upgrade changes nothing on its own. Once _APP_PWNED_PASSWORDS_DSN points at a service, an unreachable service returns a 503 rather than passing the password. Worth a line in the release notes: set the DSN to get protection.
• Release: the users collection gains an attribute and an index, so this must ship in a minor with the new version mapped to V25 in Migration::$versions, following how V25 was extended on main after 2.2.0.

Test Plan

• Unit: tests/unit/Auth/Validator/PasswordPwnedTest.php, 19 cases with a named fake fetch adapter and in-memory cache: defaults, policy flags, sessions requiring an enabled policy, breach state, non-required outage, leaked, clean, padding, case, threshold, caching per prefix and endpoint, failed lookups not cached, surfacing an outage and an unexpected status, a single breach being enough, base rules, and lookups going to the configured endpoint. The lookup tests assert the k-anonymity guarantee itself, that neither the password nor its full hash nor the identifying suffix leaves the server, rather than mirroring the URL format.
• E2E PoliciesBase (console-client and custom-server suites): enable, disable, documented defaults, the sessions toggle, option preservation, empty body, invalid types, unauthenticated.
• E2E PoliciesPasswordPwnedIntegrationTest, 14 cases: a freshly created project rejecting a breached password with no policy change, policy off and on across users create, users password update, account create, account password update and recovery, hashed import bypass, password clearing, the sessions matrix (no check, record only, blocked until reset), anonymous email and phone conversion against every password policy, existing passwords not being re-validated, and the passwordPwned flag: null/false/true transitions on users get, users list, account get and account create, list filtering by equal true/false, isNull and isNotNull with every returned row verified, clearing on change, forced reset still recording, outage leaving state untouched, and non-whitelisted query attributes rejected.
• Ran locally in the container against volumes migrated with migrate from the previous schema: both policy suites (92 each), the integration suite (17), Users (52), Account server, password strength, password dictionary, and the unit suite. Pint, PHPStan (level 4), and Rector check are clean.
• One unrelated failure in that environment: ProjectsConsoleClientTest::testDeleteProjectWithMultiDB, which needs MongoDB and was verified failing identically with these changes reverted.

Related PRs and Issues

• None

Checklist

• Have you read the Contributing Guidelines on issues?
• If the PR includes a change to an API's metadata (desc, label, params, etc.), does it also include updated API specs and example docs?

🤖 Generated with Claude Code