Configure the password authenticator

This authenticator lets you enforce the use of passwords when users sign in to Okta or an app. You can customize complexity requirements, apply password rules to groups or individuals, and set lockout conditions. End users can reset forgotten passwords without the aid of a help desk.

The password authenticator is active by default for Okta users. To use the password authenticator, you have to configure a password policy and rules.

This authenticator is a knowledge factor and fulfills the requirements for user presence. See Multifactor authentication.

Recommendations for strong passwords

Define password policies that have password lockout, history, a minimum age, a minimum length of eight characters, and that disallow common passwords. Here's a sample configuration:

• Password lock out to 10+
• Minimum password history of 24
• Minimum age of one hour
• Minimum length of 12 characters
• Restrict the use of common passwords

Before you begin

• Create groups if you want to use them in a password policy. See Manage groups.
• Create network zones if you want to use them in a password policy. See Configure a network zone.

Add a password policy

1. In the Admin Console, go to SecurityAuthenticators.

2. On the Setup tab, click ActionsEdit for the Password item.
3. Click Add New Password Policy.

Configuration options

1. Set the conditions for your password policy:

   Field	Value
   Policy name	Enter a descriptive name for this policy.
   Policy description	Enter a description of what this policy does, and to whom it applies.
   Add group	Enter the groups of users that this policy applies to.
   Applies to	Select the authentication provider.
   Minimum length	Require a minimum number of characters in passwords. The minimum length is four characters. The maximum length is 30 characters.
   Complexity requirements	Require various character types and other attributes to make passwords more complex. You can use Active Directory password requirements if you have AD-sourced users. Select from these options to construct your password complexity requirements: Lower case letter: Require at least one lower-case letter in the password. Upper case letter: Require at least one upper-case letter in the password. Number (0-9): Require at least one number from zero to nine in the password. Symbol (e.g., !@#$%^&*): Require at least one symbol in the password. Does not contain part of username: Don't allow parts of the username in the password. Does not contain first name: Don't allow the user's first name in the password. Does not contain last name: Don't allow the user's family name in the password. Early Access release. See Enable self-service features. Use an OEL statement to block restricted content: Block the use of custom words in passwords using Okta Expression Language. A field appears when you select this option. Enter an expression in the field. You can put each word in its own statement, like password.value.contains("BlockedWord1"). For multiple words, use the OR operator between each expression, like password.value.contains("BlockedWord1") OR password.value.contains("BlockedWord2"). See Okta Expression Language in Okta Identity Engine. Users see an error message if they try to use a custom word in their new password.
   Common password check	Prevent users from choosing commonly used passwords like "Password" and "11111111". Okta checks the user's password choice against the list of 1 million commonly used passwords. Combined with case-sensitive matching, this list covers over 2.5 billion common passwords.
   Password age	Configure how long users can use passwords, how often they can reuse them, and when they're prompted to change them. Enforce password history for last: Enter the number of distinct passwords that a user must create before they can reuse a previous password. This prevents users from reusing a previous password for a specified period. You can configure this setting from 1 to 30 passwords. Minimum password age is: Enter the minimum time interval required between password changes. This setting prevents users from bypassing the enforce password history requirement. You can configure this setting for up to 9,999 minutes. Password expires after: Enter the number of days that a password remains valid before it must be changed. When a user's password expires, they must change it to sign in to Okta. You can configure this setting for up to 999 days. Users don't receive an expiration warning if the value is fewer than six days. For AD and LDAP sourced users: The Password expires after setting doesn't appear. The expiration date can vary and is imported from AD and LDAP. Prompt user: Enter the number of days before password expiration that users are prompted to change their password. Users can change their password when prompted, or wait until the expiration date. You can configure this setting for up to 999 days. Users don't receive an expiration warning when the value is less than six days.
   Lock out	Configure these options: The number of times an incorrect password can be entered before the account is locked. How long the account remains locked. Send users a lockout failure email when their account is locked. See Block suspicious password attempts from unknown devices To prevent AD and Lightweight Directory Access Protocol (LDAP) lockouts, verify that the number of unsuccessful attempts is lower than the failed sign-in attempt limit configured in AD and LDAP.

2. Click Create Policy.
3. Select the policy in the policy list.
4. Click Add Rule.

5. Configure the following options:

   Field	Value
   Rule name	Enter a name for the rule.
   Exclude users	Enter the names of the users that you want to exclude.
   IF User's IP is	Anywhere: Apply the rule to all users regardless of whether their IP address is listed in the Public Gateway IP list. In zone: Apply the rule to users in all or specific network zones. Not in zone: Apply the rule to exclude users in all zones or in specific zones. See Network zones for information on the Public Gateway IP list and other IP Zones features. If specifying a zone, remember that IPs are dynamic and IP geolocation isn't guaranteed.
   THEN User can perform self-service	Password change (from account settings): Allow users to change their password with the perform self-service password reset option. Password reset: Allow users to perform self-service password resets through the Forgot password? link on the Sign-In Widget. Unlock account: Allow users to unlock their account by clicking the Unlock account? link on the Sign-In Widget. When you select this option, LDAP-sourced Okta user accounts are unlocked in Okta but remain locked in the on-premises LDAP instance. If you don't allow self-service unlock, see Reset a user password for other options.
   AND Users can initiate recovery with	Okta Verify (push notification only): Allow users to initiate recovery with Okta Verify push notifications. See Configure the Okta Verify authenticator. In self-service password reset scenarios, when you select Okta Verify with push as the only authenticator, and you've activated User Enumeration Prevention for recovery, users still receive number matching challenges even if you've turned that setting off. Phone: Allow users to initiate recovery with either text messages or voice phone calls. See Configure the phone authenticator authenticator. Email: Allow users to initiate recovery with an email message that contains a one-time password or a magic link. See Configure the email authenticator. Google Authenticator: Allow users to initiate recovery with a one-time passcode from Google Authenticator. See Google Authenticator.
   AND Additional verification is	Not required: Don't require additional verification from users during recovery. Any enrolled authenticator used for MFA/SSO: Allow users to use any enrolled authenticator for recovery. Only Security Question: Only allow users to use a security question for recovery. See Configure the security question authenticator. Admins can determine whether an authentication challenge must be completed before the user enters their password. In an authentication policy rule, configure the AND User must authenticate with option. See Add an authentication policy rule.

6. Click Create rule.

Add the password authenticator to the authenticator enrollment policy

1. In the Admin Console, go to SecurityAuthenticators.

2. Click the Enrollment tab.
3. Add the authenticator to a new or an existing authenticator enrollment policy. See Create an authenticator enrollment policy.

Edit or delete password policies and rules

You can't edit or delete the password authenticator, but you can edit or delete the policies that are associated with it.

You may need to update any enrollment, authentication, and global session policies that use include this authenticator if you edit or remove a password policy or rule.

1. In the Admin Console, go to SecurityAuthenticators.

2. On the Setup tab, click ActionsEdit for the Password item.
3. Select a policy from the list to see its Edit and Delete options.
4. Select a rule in the policy to see its options. To edit, click the pencil icon. To delete, click X.

End-user experience

End users are always prompted for a password unless an authentication policy rule for passwordless authentication is enabled. In AD, locked-out Okta users can use self-service account unlock, but only an admin can unlock a locked LDAP-sourced account.

Related topics

Self-service account recovery

Multifactor authentication