Appwrite adds breached-password detection to Auth

Appwrite has added breached-password detection to Appwrite Auth, checking users’ passwords against the Have I Been Pwned breach database. The feature is available on Appwrite Cloud and self-hosted Appwrite 2.3 and later. It is intended to catch passwords that meet strength rules but have already appeared in data breaches, a risk that can enable credential-stuffing attacks when people reuse passwords.

The checks run at sign-up, email-and-password sign-in, password changes, and password recovery. Appwrite records the latest result on each user as a passwordPwned flag, and teams can also choose to reject breached passwords when users set one or to block sign-in until a password is reset. On Appwrite Cloud, checking and recording are enabled by default, while rejection and sign-in blocking require teams to opt in.

The lookup is designed to avoid sending a password or its full hash to the external service. Appwrite hashes the password with SHA-1 and shares only the first five characters of that hash; it then checks the returned matching suffixes on its own servers. Appwrite also requests padded responses, so the response size does not reveal additional information. Results are cached to avoid repeating the same lookup unnecessarily.

The feature complements Appwrite’s existing password controls, which cover strength, common-password blocking, password reuse within an app, and personal information in passwords. Those measures assess password characteristics or reuse, while a breach check detects whether a password has surfaced in leaked data. Appwrite says a password that was clean when first set can be flagged during a later sign-in if it appears in a breach in the meantime.

If the breach-check service is unavailable, Appwrite fails the request with a general_pwned_passwords_unavailable error rather than allowing the password through. With rejection enabled, an attempt to set a breached password returns password_pwned; with sign-in blocking enabled, the user must reset the password. The server-side Users API applies the rejection policy when creating users or updating passwords, so builders need to account for these outcomes in both user-facing flows and server code.