Password policy scope

The scope of a password policy applies to an identity store. Password policies are reusable through multiple identity stores, but an identity store can only have a single password policy applied.

Baseline password format

In general, passwords can take on the following form without any specific complexity requirements or restrictions applied:

• Can be up to 64 characters in length.
• Can contain any uppercase or lowercase letter from the Latin alphabet in Unicode.
• Can contain any digits from 0 to 9.
• Can contain special characters (for example, # $ % & ! ' ( )- . @ ^ _' { } ~ ?).

Password strength settings

Breached password detection

Data leaks pose the number one security risk to accounts because sensitive information, such as exposed passwords, falls into the hands of bad actors. Breached password detection prevents customers from using passwords that were previously part of data breaches.

You can simply enable this feature in a password policy and assign it to any identity store. Once enabled, Strivacity will automatically screen customer-provided passwords against a database of leaked passwords.

We’ve implemented breached password detection to every part of the self-service experience and the Admin Console where your customers or administrators have to set passwords:

• self-service registration
• self-service password reset
• self-service password reset by email
• account password reset by customer service or administrators

The method we use

We primarily use the open-source package of breached passwords made available by Have I Been Pwned (HIBP). HIBP hashes original values to hide personally identifiable information (PII). You can encourage your customers to get familiar with good password practices and to screen their passwords for the rest of their accounts e.g. at HIBP's pwned password service.

✅

We don't store the HIBP passwords in human-readable form. Only your customers will know by trial and error if their password has been leaked when using the Strivacity password breach detection service.

Password strength

While password strength intends to prevent the use of simple-to-guess passwords, complexity requirements can still lead customers to a bad experience and let them succumb to common, weak passwords.

✅

Breached password detection

Commonly used passwords have probably been leaked at some time in the past. You can prompt your customers to create safer passwords by implementing breached password detection. If breached password detection is on, you should consider skipping password strength configuration. Having both on at the same time can increase password usability issues. The safest, usable option is breached password protection. See the NIST 800-63-3 guidelines about “5.1.1.2 Memorized Secret Verifiers” for more details.

Password guessing avoidance

This setting helps enhance security by preventing customers from using easily guessable personal information in their passwords. Specifically, it restricts the use of the customer's first name, last name, or any part of their username in their password, reducing the risk of weak or predictable passwords.

✅

You can switch on password guess avoidance for each personal data field separately.

When enabled, password guessing avoidance forbids the use of character strings split by non-word characters ($%&'()-.@^_`'{}~ and space) longer than 3 characters in the username, first name, or last name.

First name and last name fields

If password guessing avoidance is applied for name fields, any part of the name split by non-word characters and longer than four characters can't be included in passwords.

The 3-character floor applies because of multipart names and prefixes. Character strings like de, da, di, o, von, van, etc. would be excluded from passwords, making password creation unnecessarily difficult and creating a poor experience for customers.

Username fields

If password guessing avoidance is applied to usernames, any word-character part of the username split by non-word characters and longer than three characters can't be included in passwords.

Examples

• First name: Alma, Last name: von Rosenberg, username: alma1rosenberg
• First name: Pilar, Last name: del Castillo, username: pilar86user
• First name: Jeff, Last name: O'Hara, username: o_hara
• First name: Min, Last name: Yong, username: @min1996yong

First name Customers with first names longer than three characters, such as Alma, Pilar, and Jeff, won't be allowed to use their name in their passwords, but Min could be included in the password.

Last name Prefixes von, del, and o could be used in passwords, but the use of Rosenberg, Castillo, Hara, and Yong are not allowed in passwords.

Username Each username is split by non-word characters: alma-1-rosenberg, pilar-86-user, o-hara, min-yong, and each word character string is analyzed.

• neither 'alma' nor 'rosenberg' can be included in the password
• neither 'pilar' nor 'user' can be included in the password
• 'o' can be part of the password, but 'hara' can't be included
• 'min' can be part of the password, but 'yong' can't be

🚧

Password guessing avoidance only analyses word charachter strings. It does not extend to the use of non-word character strings, e.g. numeric characters in usernames. For further character restriction options, you can check repeated and sequential character restriction.

📘

Password guessing avoidance is case insensitive which means that changing the letter case will still not allow customers to include forbidden strings in passwords.

Repeated character restriction

When enabled, you can define how many times a character is allowed to repeat consecutively in a password. Repeated character restriction is case-sensitive which allows the lower and upper case of the same letter to alternate.

Sequential character restriction

When enabled, you can limit the length of numerical character sequences in a password. Sequential numbers over a specified length can't be a part of passwords.

Password requirement indicator

If enabled, the customer will see a dynamic indication of which password requirements are being met while creating a new password.

Password history settings

Password reuse restriction

The password reuse restriction setting helps enforce stronger security by preventing customers from reusing their previous passwords. This reduces the risk of compromised accounts due to predictable password patterns.

• Customers are not allowed to use their last ... passwords: When enabled, this setting prevents customers from reusing a specified number of their most recent passwords when creating a new one. Administrators can define how many past passwords are restricted.

  ❗️

  Setting this value to 1 means customers cannot reuse their current password, but their last password before that is allowed.

• Customers are not allowed to reset their password to the one(s) they have had in the last ... days: When enabled, this setting prevents customers from resetting their password to one they have used within a specified time frame. Administrators can define the number of days during which previous passwords cannot be reused.

Password age restriction

You can set the maximum age of passwords. Customers will be required to change their password after the specified lifetime is up.