Passwords remain one of the most common ways for customers to secure their accounts, which makes it critical to enforce standards that balance protection with ease of use. Strivacity provides configurable password quality settings that let administrators define how passwords are created, validated, and managed across identity stores. By tailoring these settings, brands can reduce the risk of weak or compromised passwords while keeping the experience as smooth as possible for customers.

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 256 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 in 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, for example, 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 guessing 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 passwords after the specified lifetime is up.

Restricted words

Restricted words let you block specific terms from being used in customer passwords. This feature helps you prevent weak or brand-related passwords (for example, your company name) and improve overall password security.

Restrictions are case insensitive, meaning variations such as example, Example, or EXAMPLE are treated the same.

Uploading restricted word lists

You can create and manage custom dictionaries of banned words by uploading plain text files. Each file:

• Must contain one word per line.
• Has no limit on the number of words or files.
• Cannot exceed the global storage limit of 10 MB across all uploaded files.
• Allows a maximum word length of 64 characters.
• Is validated during upload. If errors are found (such as whitespace or invalid encoding), the system rejects the file and displays up to 100 error messages with the problematic words.

❗️

If a file contains errors, none of its contents will be accepted. You’ll need to fix the issues and re-upload the file.

Managing restricted word files

• Add a new file: Select Import file, drag & drop or browse for a .txt file, and enter a display name and optional description.
• Download a file: Use the file’s action menu to download its contents.
• Delete a file: Use the file’s action menu to permanently remove it.
• Edit metadata: Update the display name or description without re-uploading the file.

Changes are saved automatically; there is no save button on this tab.

Example use case

A retail company might want to prevent customers from using its brand name in passwords. For example, if example is uploaded as a restricted word, customers will be blocked from creating passwords like Example123!, myexamplepw, or any variation of the restricted word.