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 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. Use Active Directory (AD) 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 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. For AD and LDAP sourced users: The Password expires after N days setting doesn't appear. The expiration date can vary and is imported from AD and Lightweight Directory Access Protocol (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 To prevent AD and 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. 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. 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

Users are always prompted for a password unless an authentication 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.

Related topics

Self-service account recovery

Multifactor authentication