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

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 Manage network zones.

Add a password policy

1. In the Admin Console, go to Security > Authenticators.

2. On the Setup tab, click Actions > Edit 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. For Active Directory (AD)-sourced users (including those using delegated authentication), this setting doesn't enforce the minimum length. The AD password policy enforces the minimum length, regardless of the value that you set here.
   Complexity requirements	Require various character types and other attributes to make passwords more complex. These complexity requirements apply to Okta, Active Directory (AD), and Lightweight Directory Access Protocol (LDAP)-sourced users. Select from these options to configure 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. Maximum N consecutive repeating characters: Only allow a character to be repeated this number of times. Enter the number of consecutive repeated characters that you want to allow. This option is available only if you selected Okta as the authentication provider. Note: If you have AD-sourced users (including those using delegated authentication) you must select the option Use Active Directory requirements. For these users, AD enforces the password complexity, not Okta. If you select Custom Requirements and choose all character-type options (lower case, upper case, number, and symbol), Okta doesn't enforce them all. By default, the AD password policy requires only three of these character types, and the AD enforcement takes precedence over the options that you set here. The Custom Requirements checkbox selections control only what Okta displays to end users as guidance and they don't change what AD requires. To change this behavior, you must update your AD complexity policy.
   Block restricted content	Use an OEL statement to block restricted content: Block the use of custom words in passwords using Okta Expression Language. Select this option and 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. Okta uses this setting for all authentication providers: Okta, AD, and LDAP-sourced users (including those using delegated authentication). This check always runs on the Okta side. For AD-sourced users (including those using delegated authentication), Okta evaluates the password against this rule before sending the password to AD.
   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. This check applies to all authentication providers, including AD-sourced users (including those using delegated authentication). Okta evaluates the password against this check before sending the password to AD.
   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 N passwords: 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 N units: Enter the minimum time interval required between password changes. This setting prevents users from bypassing the Enforce password history for last N passwords requirement. You can configure this setting for up to 9,999 minutes. Password expires after N days: 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. This option is available only if you selected Okta as the authentication provider. For AD and LDAP-sourced users, the expiration date can vary and is imported from AD and LDAP. Prompt user N days before password expires: 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 conditions for handling lockouts: Lock out user after N unsuccessful attempts: The number of times users can enter an incorrect password before the account is locked. Account is automatically unlocked after N minutes: The length of time that the account remains locked. Show lock out failures: Show lockout failures in the Admin Console. Send lockout email to user: Send users a lockout failure email when their account is locked. See Block suspicious password attempts from unknown devices Note: To prevent AD and LDAP lockouts, ensure that the number of unsuccessful attempts in Okta is significantly lower than the failed sign-in limit configured in your directory service. As a best practice, set the Okta lockout limit to no more than half of the AD/LDAP limit. For example, if AD permits 10 failed attempts, configure the Okta limit to five or fewer.

   Note:

   Changes to password settings take effect the next time a user resets their password and when the password expires. New user accounts are subject to your current password settings when you create the account.

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. When Okta Verify with Push is the only authenticator, users receive a number matching challenge regardless of whether you enable User Enumeration Prevention for recovery. Phone (SMS / Voice call): Allow users to initiate recovery with either text messages or voice phone calls. See Configure the phone authenticator. Email: Allow users to initiate recovery with an email message that contains a one-time passcode 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. Note: Admins can determine whether an authentication challenge must be completed before the user enters their password. In an app sign-in policy rule, configure the AND User must authenticate with option. See Add an app sign-in policy rule.

6. Click Create rule.

Add the password authenticator to the authenticator enrollment policy

1. In the Admin Console, go to Security > Authenticators.

2. Click the Enrollment tab.
3. Add the authenticator to a new or an existing 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 Security > Authenticators.

2. On the Setup tab, click Actions > Edit 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

Users are always prompted for a password unless an app sign-in policy rule for passwordless authentication is enabled.

If a user's account is locked, they can regain access by clicking Unlock account on the Sign-In Widget. Okta displays other ways that the user can authenticate to regain access.

To reset the password, the user clicks the arrow beside their name in the upper-right corner of the Okta End-User Dashboard. Then, the user selects Settings. In the Security Methods section, the user clicks Reset next to Password.

In AD, locked-out Okta users can use self-service account unlock, but only an admin can unlock a locked LDAP-sourced account.