Files
supabase/apps/docs/content/guides/auth/password-security.mdx
Danny White 24be387cdb docs: use sign in terminology across guides and style guides (#49877)
## What kind of change does this PR introduce?

Docs update. Aligns documentation and style guides with the **Sign in /
Sign out / Sign up** platform standard.

Closes DOCS-1328. Related to
[#49874](https://github.com/supabase/supabase/pull/49874).

## What is the current behavior?

Docs style guides prefer _login_ / _log in_. Guide prose uses mixed
login and sign in wording.

## What is the new behavior?

- [WORD_LIST.md](apps/docs/WORD_LIST.md) and
[copywriting.mdx](apps/design-system/content/docs/copywriting.mdx)
document the sign in standard
- Design-system auth examples updated
- Guide prose and API reference spec descriptions updated

### Terminology

**Standard:** Use _sign in_, _sign out_, and _sign up_ as verbs. Use
_sign-in_, _sign-out_, and _sign-up_ as nouns and adjectives. Match
Studio UI labels (**Sign in**, **Sign out**, **Sign up**).

**Preserved intentionally:**

| Category | Keep as-is | Example |
| -------- | ---------- | ------- |
| Feature name | social login | `/social-login`, `features.mdx` heading,
OAuth provider section |
| URL slugs | `login` in paths | `/phone-login`, `/login-flows`,
`choosing-login-flow` |
| CLI | `supabase login` / `supabase logout` | Reference ids
`supabase-login` / `supabase-logout`; executable commands unchanged |
| SDK methods | `logout()` | Kotlin/Swift method names in API reference
titles and examples |
| Third-party UI | Provider product labels | Facebook Login, Kakao
Login, portal **Login** buttons |
| Postgres | Database terminology | login privileges, login credentials,
login via role |
| Audit/logging | Log prose | "Generates the following **log** in the
Postgres Logs" |
| Code and routes | Paths and filenames | `app/login/`, `Login.tsx`,
`demos/android-login` |
| External URLs | Third-party login pages | `dash.cloudflare.com/login`,
`console.neon.tech/login`, `vercel.com/login` |
| API identifiers | Event and field names | Audit actions
`login`/`logout`, `should_logout_user` |

## To test

- Run `pnpm lint:mdx` in `apps/docs`
- Spot-check `features.mdx`, `social-login.mdx`, and a provider guide
(e.g. Facebook, Kakao)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Documentation**
* Standardized authentication terminology across guides, reference
material, CLI documentation, and copywriting guidance using “sign in,”
“sign out,” and “sign up.”
* Updated authentication instructions, headings, link text, examples,
and SSO guidance for clearer, more consistent wording.
* Corrected related grammar, spelling, hyphenation, and documentation
links while preserving established product names and implementation
commands.
* **Style**
  * Refined code examples with consistent import ordering and spacing.
* **Examples**
* Updated authentication button and menu labels to “Sign in” and “Sign
out.”
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-09-04 09:10:25 +10:00

84 lines
5.0 KiB
Plaintext

---
title: 'Password security'
subtitle: 'Help your users to protect their password security'
---
A password is more secure if it is harder to guess or brute-force. In theory, a password is harder to guess if it is longer. It is also harder to guess if it uses a larger set of characters (for example, digits, lowercase and uppercase letters, and symbols).
This table shows the _minimum_ number of guesses that need to be tried to access a user's account:
| Required characters | Length | Guesses |
| -------------------------------------------- | ------ | ---------------- |
| Digits only | 8 | ~ 2<sup>27</sup> |
| Digits and letters | 8 | ~ 2<sup>41</sup> |
| Digits, lower and uppercase letters | 8 | ~ 2<sup>48</sup> |
| Digits, lower and uppercase letters, symbols | 8 | ~ 2<sup>52</sup> |
In reality though, passwords are not always generated at random. They often contain variations of names, words, dates, and common phrases. Malicious actors can use these properties to guess a password in fewer attempts.
There are hundreds of millions (and growing!) known passwords out there. Malicious actors can use these lists of leaked passwords to automate sign-in attempts (known as credential stuffing) and steal or access sensitive user data.
## Password strength and leaked password protection
To help protect your users, Supabase Auth allows you fine-grained control over the strength of the passwords used on your project. You can configure these in your project's [Auth settings](/dashboard/project/_/auth/providers?provider=Email):
- Set a large minimum password length. Anything less than 8 characters is not recommended.
- Set the required characters that must appear at least once in a user's password. Use the strongest option of requiring digits, lowercase and uppercase letters, and symbols. The allowed symbols are: ``!@#$%^&*()_+-=[]{};'\:"|<>?,./`~``
- Prevent the use of leaked passwords. Supabase Auth uses the open-source [HaveIBeenPwned.org Pwned Passwords API](https://haveibeenpwned.com/Passwords) to reject passwords that have been leaked and are known by malicious actors.
<Admonition type="note">
Leaked password protection is available on the Pro Plan and above.
</Admonition>
## Require reauthentication when changing password
Users will need to be recently logged in to change their password without requiring reauthentication. (A user is considered recently logged in if the session was created within the last 24 hours.) If disabled, a user can change their password at any time.
When enabled, a `nonce` will be sent to the user and this nonce must be validated before the a password change can occur. This can be triggered with the [reauthenticate()](/docs/reference/javascript/auth-reauthentication) API call.
```
const { error } = await supabase.auth.reauthenticate()
...
// send the nonce provided by the user with the password change
const { data, error } = await supabase.auth.updateUser({
email: 'user@email.com',
nonce: `${nonce}`,
password: "new_super_strong_password"
})
```
## Require current password when changing password
Enforce that users supply their current password when trying to change the password. When enabled, the password change request will validate that the current password is correct before updating the user's password.
```
const { data, error } = await supabase.auth.updateUser({
email: 'user@email.com',
current_password: "correct_current_password",
password: "new_super_strong_password"
})
```
## Additional recommendations
In addition to choosing suitable password strength settings and preventing the use of leaked passwords, consider asking your users to:
- Use a password manager to store and generate passwords.
- Avoid password reuse across websites and apps.
- Avoid using personal information in passwords.
- Use [Multi-Factor Authentication](/docs/guides/auth/auth-mfa).
## Frequently asked questions
### How are passwords stored?
Supabase Auth uses [bcrypt](https://en.wikipedia.org/wiki/Bcrypt), a strong password hashing function, to store hashes of users' passwords. Only hashed passwords are stored. You cannot impersonate a user with the password hash. Each hash is accompanied by a randomly generated salt parameter for extra security.
The hash is stored in the `encrypted_password` column of the `auth.users` table. The column's name is a misnomer (cryptographic hashing is not encryption), but is kept for backward compatibility.
### How will strengthened password requirements affect current users?
Existing users can still sign in with their current password even if it doesn't meet the new, strengthened password requirements. However, if their password falls short of these updated standards, they will encounter a `WeakPasswordError` during the `signInWithPassword` process, explaining why it's considered weak. This change is also applicable to new users and existing users changing their passwords, ensuring everyone adheres to the enhanced security standards.