Eliminate bad passwords using Microsoft Entra Password Protection - How are passwords evaluated

When a user changes or resets their password, the new password is checked for strength and complexity by validating it against the combined list of terms from the global and custom banned password lists.

Even if a user's password contains a banned password, the password may be accepted if the overall password is otherwise strong enough. A newly configured password goes through the following steps to assess its overall strength to determine if it should be accepted or rejected.

 Note

Password protection in Microsoft Entra ID doesn't correlate with password protection for on-premises users. The validations in password protection aren't consistent for users across the two services. Ensure the users in your tenant meet the required password parameters for their respective service when initially setting their password or completing SSPR.

Step 1: Normalization

A new password first goes through a normalization process. This technique allows for a small set of banned passwords to be mapped to a much larger set of potentially weak passwords.

Normalization has the following two parts:

• All uppercase letters are changed to lower case.

• Then, common character substitutions are performed, such as in the following example:

   

  Original letter	Substituted letter
  0	o
  1	l
  $	s
  @	a

Consider the following example:

• The password "blank" is banned.
• A user tries to change their password to "Bl@nK".
• Even though "Bl@nk" isn't banned, the normalization process converts this password to "blank".
• This password would be rejected.

Step 2: Check if password is considered banned

A password is then examined for other matching behavior, and a score is generated. This final score determines if the password change request is accepted or rejected.

Fuzzy matching behavior

Fuzzy matching is used on the normalized password to identify if it contains a password found on either the global or the custom banned password lists. The matching process is based on an edit distance of one (1) comparison.

Consider the following example:

• The password "abcdef" is banned.

• A user tries to change their password to one of the following:

  • 'abcdeg' - last character changed from 'f' to 'g'
  • 'abcdefg' - 'g' appended to end
  • 'abcde' - trailing 'f' was deleted from end

• Each of the above passwords doesn't specifically match the banned password "abcdef".

  However, since each example is within an edit distance of 1 of the banned term 'abcdef', they're all considered as a match to "abcdef".

• These passwords would be rejected.

Substring matching (on specific terms)

Substring matching is used on the normalized password to check for the user's first and last name, and the tenant name. Tenant name matching isn't done when validating passwords on an AD DS domain controller for on-premises hybrid scenarios.

 Important

Substring matching is only enforced for names, and other terms, that are at least four characters long.

Consider the following example:

• A user named Poll who wants to reset their password to "p0LL23fb".
• After normalization, this password would become "poll23fb".
• Substring matching finds that the password contains the user's first name "Poll".
• Even though "poll23fb" wasn't specifically on either banned password list, substring matching found "Poll" in the password.
• This password would be rejected.

Score Calculation

The next step is to identify all instances of banned passwords in the user's normalized new password. Points are assigned based on the following criteria:

1. Each banned password found in a user's password is given one point.
2. Each remaining character that isn't part of a banned password is given one point.
3. A password must be at least five (5) points to be accepted.

For the next two example scenarios, Contoso is using Microsoft Entra Password Protection and has "contoso" on their custom banned password list. Let's also assume that "blank" is on the global list.

In the following example scenario, a user changes their password to "C0ntos0Blank12":

• After normalization, this password becomes "contosoblank12".

• The matching process finds that this password contains two banned passwords: "contoso" and "blank".

• This password is then given the following score:

  [contoso] + [blank] + [1] + [2] = 4 points

• As this password is under five (5) points, it's rejected.

Let's look a slightly different example to show how more complexity in a password can build the required number of points to be accepted. In the following example scenario, a user changes their password to "ContoS0Bl@nkf9!":

• After normalization, this password becomes "contosoblankf9!".

• The matching process finds that this password contains two banned passwords: "contoso" and "blank".

• This password is then given the following score:

  [contoso] + [blank] + [f] + [9] + [!] = 5 points

• As this password is at least five (5) points, it's accepted.

 Important

The banned password algorithm, along with the global banned password list, can and do change at any time in Azure based on ongoing security analysis and research.

For the on-premises DC agent service in hybrid scenarios, updated algorithms only take effect after the DC agent software is upgraded.

Microsoft Documentation: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad#how-are-passwords-evaluated