Password safety
Two things stand between an account and a weak password: a structural rule the instance enforces on every path that sets a password, and a breached-password check the sign-up form runs in the browser against Have I Been Pwned (HIBP).
The rule the instance enforces
Install, sign-up and password reset all validate the password server-side, so a direct API call cannot bypass what the form asks for:
| Rule | Value |
|---|---|
| Length | 8 to 256 characters |
| Must contain | at least one digit, and at least one of $ ! @ % & * # ^ ( ) _ + = - |
| Must not | start or end with whitespace |
A password that fails returns 400 with the first failing rule as its message (Password must include at least one number, …). The upper bound exists because Argon2id's cost grows with input length; an unbounded password would make hashing an attacker-controlled expense.
The breached-password check
The sign-up form checks the password against HIBP's range API before it lets you submit, and refuses a known-breached one with That password isn't safe to use. Please choose a different one.
Your password never leaves the browser
The form hashes the password with SHA-1 (only for this query — storage uses Argon2id), sends the
first five hex characters of that hash to api.pwnedpasswords.com/range/, and compares the
returned suffixes locally (k-anonymity, with response padding requested). If HIBP cannot be reached
within five seconds the check is skipped rather than blocking sign-up.
This check runs in the browser at sign-up only. The instance itself does not query HIBP, and there is no change-password screen in this release — see Account security for the ways into an account and how to recover one.
Related
- Account security — two-factor, passkeys, linked providers, re-authentication.
- Security — control plane and daemon security.
Last updated on