/
Contact usSee pricingStart building

    About B2B Saas Authentication

    Introduction
    Stytch B2B Basics
    Integration Approaches
      Full-stack overview
      Frontend (pre-built UI)
      Frontend (headless)
      Backend
    Next.js
      Routing
      Authentication
      Sessions
    Migrations
      Overview
      Reconciling data models
      Migrating user data
      Additional migration considerations
      Zero-downtime deployment
      Defining external IDs for members
      Exporting from Stytch
    Custom Domains
      Overview

    Authentication

    Single Sign On
    • Resources

      • Overview
        External SSO Connections
        Standalone SSO
    • Integration Guides

      • Start here
        Backend integration guide
        Headless integration guide
        Pre-built UI integration guide
    OAuth
    • Resources

      • Overview
        Authentication flows
        Identity providers
        Google One Tap
        Provider setup
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Connected AppsBeta
      Setting up Connected Apps
      About Remote MCP Servers
    • Resources

      • Integrate with AI agents
        Integrate with a remote MCP server
    Sessions
    • Resources

      • Overview
        JWTs vs Session Tokens
        How to use Stytch JWTs
        Custom Claims
    • Integration Guides

      • Start here
        Backend integration
        Frontend integration
    Email OTP
      Overview
    Magic Links
    • Resources

      • Overview
        Email Security Scanner Protections
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Multi-Factor Authentication
    • Resources

      • Overview
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Passwords
      Overview
      Strength policies
    UI components
      Overview
      Implement the Discovery flow
      Implement the Organization flow
    DFP Protected Auth
      Overview
      Setting up DFP Protected Auth
      Handling challenges
    M2M Authentication
      Authenticate an M2M Client
      Rotate client secrets
      Import M2M Clients from Auth0

    Authorization & Provisioning

    RBAC
    • Resources

      • Overview
        Stytch Resources & Roles
        Role assignment
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
    SCIM
    • Resources

      • Overview
        Supported actions
    • Integration Guides

      • Using Okta
        Using Microsoft Entra
    Organizations
      Managing org settings
      JIT Provisioning

    Testing

    E2E testing
    Sandbox values
Get support on SlackVisit our developer forum

Contact us

B2B Saas Authentication

/

Guides

/

Authentication

/

Passwords

/

Strength policies

Passwords strength policies

Stytch offers two different password strength strategies for you to choose from, zxcvbn and Lowercase Uppercase Digits Special Characters (LUDS). On top of these two strategies, we also offer breach detection, powered by HaveIBeenPwned to protect your users from password breaches.

You may choose any mix of these strategies for your Stytch Project. For example, you may choose to use LUDS for password complexity plus breach detection, or zxcvbn without breach detection.

By default, our Passwords product uses zxcvbn for password strength and automatically protects your users against password breaches. If that doesn't fit your needs, you may configure your desired strategy by contacting support@stytch.com.

Passwords at Stytch may contain any UTF8 character, e.g. spaces, emojis, non-English characers, etc. Any of these types of characters may contribute to fullfilling the complexity requirements you choose.

zxcvbn

zxcvbn is a password strength estimation library developed originally by Dropbox. It is a complex password strength strategy that checks for the presence of dictionary words, common passwords, and common patterns. It does not explicitly check for lowercase letters, uppercase letters, digits, or special characters.

Some end users find zxcvbn to be too strict, and may be unable to create a password that meets the requirements. If you find that your users are unable to create a password that meets the requirements, you may want to consider using LUDS instead.

You can find examples of zxcvbn passwords and an interactive tool to test passwords at this hosted zxcvbn checker.

Example

If a user provides a commonly used password like, "p@ssword1", the response from our Strength check endpoint will look like the following:

{
  "breach_detection_on_create": true,
  "breached_password": false,
  "feedback": {
    "luds_requirements": null,
    "suggestions": [
      "Add another word or two. Uncommon words are better.",
      "Predictable substitutions like '@' instead of 'a' don't help very much."
    ],
    "warning": "This is a top-100 common password."
  },
  "request_id": "request-id-test-86779128-d4e7-4dd4-a588-88faa570f638",
  "score": 0,
  "status_code": 200,
  "strength_policy": "zxcvbn",
  "valid_password": false
}

You may use the warning and suggestions fields to provide feedback directly to your users to help them craft a stronger password that will pass your requirements.

LUDS

LUDS stands for Lowercase Uppercase Digits Special Characters. It is a simple password strength strategy that checks for the presence of lowercase letters, uppercase letters, digits, and special characters. It does not check for dictionary words or common passwords.

Example

For this example, we will use the following password strength policy:

  • Strength policy: LUDS
  • LUDS minimum length: 8
  • LUDS complexity: 4

If a user provides a password of, "Lorem1!", the password will be considered invalid. The password contains the necessary complexity, symbols, numbers, and upper and lower case letters, but is not of sufficient length. The response from our Strength check endpoint would look like the following:

{
	"breach_detection_on_create": true,
	"breached_password": false,
	"feedback": {
        "luds_requirements": {
            "has_digit": true,
            "has_lower_case": true,
            "has_symbol": true,
            "has_upper_case": true,
            "missing_characters": 2,
            "missing_complexity": 0
        },
		"suggestions": null,
		"warning": null
	},
	"request_id": "request-id-test-86779128-d4e7-4dd4-a588-88faa570f638",
	"score": 0,
	"status_code": 200,
	"strength_policy": "luds",
	"valid_password": false
}

You may use the missing_characters and missing_complexity fields to provide feedback to your users to help them craft a stronger password that will pass your requirements.

Breach detection

Stytch's Passwords product automatically protects your users against password breaches. We do this by checking the password against a list of known passwords that have been leaked in data breaches from HaveIBeenPwned. If the password is found in this list, we will reject the password and ask the user to choose a different one or reset their password if they have already used it previously.

Protecting your users against password breaches is a critical part of your security strategy. Password breaches are a common attack vector for hackers, and can be used to gain access to your users' accounts and compromise your app.

How to set a password strength policy

You may set or update the password strength policy for your Stytch Project via the Passwords tab in the Stytch Dashboard.

Password strength policy options

  • Strength policy type: The type of password validation policy to use – either one of our default zxcvbn policies or a custom policy using LUDS.
  • Minimum password length: When using a custom LUDS policy, the minimum number of characters required for a password. We require a minimum of at least 8 characters.
  • Number of character types: When using a custom LUDS policy, the minimum number of character types required for a password. Allowable values are 1-4. This value determines how many LUDS checks must be passed – for example, 2 means that a password with a symbol and a number is valid because two of the four LUDS requirements are met. You cannot choose which LUDS requirements are required, only how many.
  • Password strength enforcement during authentication: Determines whether or not password strength checks are applied during password authentication. During user migrations from another service with a password policy that is incompatible with Stytch's password strength policy options, you may choose to disable password strength checks during authentication.
  • Breach detection: Determines whether passwords are checked against the HaveIBeenPwned dataset during password creation and authentication, during password creation only, or never.

zxcvbn

Example

LUDS

Example

Breach detection

How to set a password strength policy

Password strength policy options