Appwrite adds Have I Been Pwned breach checks to Auth, with self-hosted setup required

Appwrite has announced breached password detection for Appwrite Auth, which compares users' passwords with the Have I Been Pwned breach corpus. The company says the feature is available on Appwrite Cloud and on self-hosted Appwrite 2.3 and later.

According to Appwrite, the check runs at sign-up, email-and-password sign-in, password change and password recovery, and the latest result is stored on each user as a passwordPwned flag. The aim is to catch passwords that satisfy strength rules but have already leaked, which Appwrite says matters because attackers replay leaked passwords against other sites in credential-stuffing attacks.

Teams get one switch and two enforcement options. The check alone only records the flag. A second option rejects breached passwords at sign-up, password change and recovery, returning a password_pwned error. A third blocks email-and-password sign-in with a breached password, returning user_password_reset_required until the user resets it. On Appwrite Cloud, checking and recording are on by default, while rejecting and blocking are opt-in. Appwrite says it keeps checking at sign-in even when only recording, so a password that was clean at sign-up can be flagged after it later leaks. Users who sign in without a password, such as through OAuth or magic URLs, keep a null flag.

On privacy, Appwrite says it hashes each password with SHA-1 and sends only the first five characters of the hash to the Pwned Passwords API, then matches the returned suffixes on its own servers. It also requests padded responses and caches range lookups. These descriptions come from the company; the post does not cite an independent review.

If the lookup service cannot be reached, Appwrite says the request fails with a general_pwned_passwords_unavailable error rather than letting the password through. The server-side Users API applies the rejection policy too, so server code needs to handle the new errors.

One detail matters for self-hosters. Appwrite says the default value of _APP_PWNED_PASSWORDS_DSN is none://localhost, which reports every password as safe, so nothing is rejected or blocked until the variable is pointed at the public API (the post gives hibp://localhost). Teams on 2.3 or later should not assume the protection is active.

Appwrite suggests a staged rollout: record first, then reject new breached passwords, contact flagged users, and finally block sign-in.

Only one source, Appwrite's own announcement, was found. Its claims about behavior, defaults and privacy have not been independently confirmed.

Revised 16 October 2026: Guth re-read the original sources and rewrote this article. The earlier version remains available as revision 1.