Skip to main content

Password protection and rules

Password rules

Clerk refers to the National Institute of Standards and Technology (NIST) guidelines to determine the character rules for passwords:

Note

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII RFC 20 characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode ISO/IEC 10646 characters SHOULD be accepted as well. To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length. Truncation of the secret SHALL NOT be performed. For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.

NIST Special Publication 800-63B

While these rules might seem lax independently, NIST's additional compromised password protection guidelines do more to prevent the use of unsafe passwords.

Also, bear in mind, that passwords are not a requirement for using Clerk. Applications can be configured to use a passwordless strategy that relies on your users being sent instead.

Reject compromised passwords

Attackers take email and password pairs leaked in other sites' data breaches and try them on your application, an attack called credential stuffing. With Reject compromised passwords enabled, Clerk checks passwords against known breach data, so a leaked password can't be set on your application, and a user who signs in with one has to replace it. It's enabled by default for new applications.

Clerk follows the National Institute of Standards and Technology (NIST) guidelines for compromised passwords:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. NIST Special Publication 800-63B

Clerk contracts with HaveIBeenPwned to compare passwords against its corpus of over 10 billion compromised credentials. Passwords are checked:

  • When a user sets or changes a password. A compromised password is rejected, and the user has to choose another.
  • When a user signs in with a password. If their correct password has been found in breach data, they're asked to reset it.

What happens at sign-in

When a user signs in with a correct password that has been found in breach data, they're asked to reset it before the sign-in completes. The reset uses the same flow as "forgot password": the user verifies with a sent to their email address or phone number, then sets a new password. If the user has no way to reset their password, the sign-in continues as normal.

Checking at sign-in catches passwords that:

  • Were added to the breach database after the user set them.
  • Were set while this setting was disabled.
  • Were imported when the user was migrated to Clerk.

If you've built a , your flow needs to handle this case. See Handle compromised passwords.

You can also mark a user's password as compromised yourself. See Manually set a password as compromised.

  • Device Trust asks for a second factor when a correct password is used on a device Clerk doesn't recognize, which also covers leaked passwords that aren't in breach data.
  • Lock accounts after failed sign-ins covers attackers who guess at a password and get it wrong.

Enable or disable it

  1. In the Clerk Dashboard, navigate to the User & authentication page.
  2. Select the Password tab and on the right side, select Update password requirements. You can enable or disable Reject compromised passwords.

Password strength

Clerk uses zxcvbn-ts for estimating the strength of passwords and leverages the Open Web Application Security Project (OWASP) guidelines to determine its handling of password strength:

Note

OWASP recommends using a password strength estimation library like zxcvbn to evaluate the strength of passwords. This can help identify weak passwords and prevent their use.

For users that set an average/weak password that complies with your organization's policies but could be stronger - Clerk also provides a gentle recommendation to use a stronger password.

Note

OWASP recommends providing feedback to users on the strength of their password and offering suggestions for improvement. This can help users create stronger passwords and improve the overall security of the application.

Manually set a password as compromised

Warning

If your instance is older than December 18, 2025, you will need to to the Reset password session task update.

Clerk provides a way to manually set a password as compromised. This is useful for blocking passwords in the case that:

  • The password has recently been added to the compromised password database.
  • The user was able to set a compromised password because protection was off at the time.

To manually set a user's password as compromised:

  1. In the Clerk Dashboard, navigate to the Users page and select the user you want to mark as compromised. You'll be redirected to the user's settings.
  2. In the Password section, if a password is set, open the three-dot menu and select Set password as compromised. A modal will open asking you to confirm the action. Complete the instructions.

Important

Setting a user's password as compromised will prevent the user from signing in until they reset their password. If you are implementing , you will need to handle the compromised password flow by yourself. See the dedicated custom flow guide for more information.

Feedback

What did you think of this content?

Last updated on

GitHubEdit on GitHub