Password quality settings

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 Latin or Unicode characters from A to Z
• Can contain any digits 0 to 9
• Can contain any of these ASCII characters: # $ % & ! ' ( )- . @ ^ _' { } ~

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 user-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 the intent of password strength is 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 can skip password strength configuration.

Repeated character restriction

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

You can limit the length of character sequences in a password. Sequential characters over a specified length can't be a part of passwords.

Password guessing avoidance

There's a good chance malicious actors will try to use your customer's personal information to take over their accounts. Attackers may pair user-identifying information or parts of it with compromised passwords or common character combinations to crack your customers' passwords faster.

Protect your customers from paving the way for cyber attackers and don't allow them to blend their personal information (username, first name, and last name) into their 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 The users 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.

Password history

Password history allows you to protect your users from falling into the habit of recycling their passwords which would pose security threats to their accounts.

Password reuse restriction

Users inadvertently open up their accounts to vulnerabilities by rotating their "tried and true" passwords. Password reuse restriction can prevent the re-use of recent passwords. If enabled, users are not allowed to pick passwords they used the last set number of times.

You can also define a time range where users are not able to pick passwords from. This way you can make sure that users won't keep on resetting their passwords until they bypass the restriction.

Password age restriction

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