Passwords
- Written for
- + Written for
- Deprecated
- + Deprecated
- Applies to
- + Applies to
Passwords
Password sign-in is the most familiar method. Atlas stores passwords safely and lets you set a strength policy that fits your product.
Enable it
Sign-in methods → Password → toggle on.
Choose whether an email address, username or phone number is the identifier.
Configure the password policy (below).
How Atlas stores passwords
Atlas never stores a raw password. It stores a verifier derived with a slow, salted hashing algorithm, and the verifier is additionally protected by per-instance encryption at rest. Verification is done in a way designed to resist timing attacks.
Password policy
Under Sign-in methods → Password, set:
Minimum length and complexity requirements.
Breached-password rejection — block passwords known to appear in public breach corpuses.
Reuse rules — prevent reusing a recent password on reset.
Password reset
Atlas provides a complete, secure reset flow out of the box:
The user requests a reset from the sign-in page.
Atlas emails a one-time, single-use reset ticket (never a token in a plain URL you have to manage).
The user sets a new password; all existing sessions can optionally be revoked.
Customize the reset email under Email & SMS templates.
Good practice
Pair passwords with passkeys or MFA for accounts that matter.
Turn on breached-password rejection — it stops the most common account-takeover vector at no UX cost.
Consider offering email codes as a lower-friction alternative for consumer apps.
Next
Go passwordless → Email & SMS codes.