Password authentication

The most common sign-in method. The user types email + password; the platform validates against the stored hash; they're in.

Enable / disable

Authentication → Password.

Enabled toggle — on by default. Turn off if your tenant is SSO-only (every user signs in via federation; no one has a password).
If you disable, existing users with passwords can't sign in via password; they have to use whatever else you have enabled.

The policy

The platform's password rules live in Settings → Password policy. From the Password page, you can also jump directly to the policy. See Password policy for the full set.

A sensible default is:

Minimum length 12.
At least one each of: uppercase, lowercase, digit, special character.
Breached-password check on (rejects passwords from public dumps).
Maximum 4 consecutive identical characters (catches aaaa patterns).

We don't recommend forcing periodic password rotation — NIST 800-63B specifically advises against routine rotation. Rotate only on suspicion of compromise.

Breached-password check

The platform can check submitted passwords against a database of breached passwords (from public dumps indexed by Have I Been Pwned and similar feeds).

When on, the platform rejects passwords that appeared in dumps with a friendly error: "This password has appeared in a known data breach. Please pick another."

The check is local on the platform side — no plaintext password ever leaves the platform.

Enable in Settings → Password policy → Breached-password check.

Password hashing

The platform uses argon2id (the OWASP-recommended modern algorithm) for password hashes. You don't configure this; it's the platform's default. The hashes are not portable to platforms that use a different algorithm (e.g., Auth0's bcrypt) — migration to / from those platforms requires either:

Force-reset-on-first-sign-in for every user.
A live-migration broker that verifies via the source platform on each first sign-in (then provisions the user with a new argon2 hash on success).

See the Migrate from Auth0 tutorial for the full pattern on the developer side.

Failed sign-ins

The platform tracks failed sign-in attempts per user (and per IP). When the policy threshold is hit, the account is temporarily locked.

Default policy:

5 failed attempts within 15 minutes → 15-minute lockout.
10 failed attempts within 1 hour → 1-hour lockout.
20 failed attempts within 24 hours → 24-hour lockout.

Configure in Settings → Authentication policy → Lockout.

A locked account refuses sign-in even with the correct password until the lockout ages out. A tenant admin can clear a lockout from the user's detail page — useful when the user is the legitimate target of someone else's brute-force.

Password reset flow

When a user clicks "Forgot password" on the sign-in page:

They enter their email.
The platform sends them a one-time link (TTL configurable; default 24 hours).
They click the link, set a new password (satisfying the policy), sign in.

The flow is the same regardless of whether the user has password as a primary, federated, or any combination of identities — the reset establishes / replaces the password identity specifically.

The platform always shows "If an account exists for this email, we've sent a reset link" — never confirming whether the email is registered. Defends against enumeration attacks.

When to disable password entirely

Some tenants run with no password sign-in:

B2B SaaS where every customer is on SSO. Sign-in is always via the customer's IdP; password is dead weight.
High-security internal tools where the team has issued WebAuthn keys to every user. Password is a downgrade path.

In both cases, disable password from the Authentication page. Existing users with passwords retain them (the records aren't deleted), but they can't use them to sign in until you re-enable. Useful for "we're trying SSO-only for a quarter; revert if necessary."

Common questions

"Can we let users sign in with just username (no email)?"

Yes — Settings → Authentication policy → Identifier lets you choose email-only, username-only, or either. Default is email-only. Username-only is unusual but works for tenants where users don't have email addresses (e.g., a children's app, or an internal numbering system).

"Can passwords be longer than X characters?"

Yes; the policy upper-bound is 256 characters (effectively unlimited). The platform truncates hashes properly; very long passwords are not a security issue.

"Can we let users sign in with email OTP first and password second?"

Not as a standard flow. Email OTP is itself a primary method (replaces password). MFA happens AFTER primary authentication, regardless of which primary method was used. If you want email-as-MFA, configure email as an MFA factor in the MFA settings, not as primary.