Entra Password Protection.....isn't

A recent incident investigation revealed something to me that I felt I should share with the community. The TL;DR of this is basically: the entropy from password length alone can be enough to bypass Entra Password Protection.

But I’m getting ahead of myself. To start:

What is Entra Password Protection?

Entra Password Protection is a hybrid infrastructure (cloud & on-prem) that dynamically checks a user password at creation against known weak passwords, and any additional custom lists you may want to add. The basic design principal of this is agent software on an on-premises domain controller will keep a specific password policy in sync with the Entra ID instance so that when an end user attempts to change their password, it is checked against this policy and either allowed or rejected. The diagram below explains the process in more detail:

The idea of which is to enhance security by preventing the use of known weak passwords as well as password elements which may be specific to your organization that can make cracking easier for attackers who have done a bit of additional recon.

Two Lists to Protect them All…

There are two key elements to how Microsoft evaluates passwords, the Global Banned Password List, and the Custom Banned Password List.

Global Banned Password List

The Global Banned Password list doesn’t seem to be a static list, and is not actually disclosed anywhere (that I can find), but instead it relies on some MS secret sauce of analysts looking for base terms that are used as the basis for weak passwords and throwing it into an algorithm (and knowing Microsoft, probably AI). They also state that no existing breach data is used in the Global Banned Password List, but not to worry because their systems are so advanced existing breach data is not needed

There are some third-party websites that enumerate millions of passwords that have been compromised in previous publicly known security breaches. It’s common for third-party password validation products to be based on brute-force comparison against those millions of passwords. However, those techniques aren’t the best way to improve overall password strength given the typical strategies used by password spray attackers.

Although the global banned list is small in comparison to some third-party bulk lists, it’s sourced from real-world security telemetry on actual password spray attacks. This approach improves the overall security and effectiveness, and the password validation algorithm also uses smart fuzzy-matching techniques. As a result, Microsoft Entra Password Protection efficiently detects and blocks millions of the most common weak passwords from being used in your enterprise.

Custom Banned Password List

The Custom Banned Password List is a list of passwords you can enter yourself in addition to the Microsoft secret AI whizz-bang list to further improve your password strength. The purpose of this list is to add elements that are specific to your organization that can be easily guessed, or determined with a little bit of recon. Things like:

  • Brand names
  • Product names
  • Organization-specific locations (company HQ, founding city, CEO’s fuck-pad, etc)
  • Org-specific internal terms

Items in this list are appended to the global banned password list and are included in the final evaluation of a password.

Sounds like a great idea right? In theory it is. There is however a flaw in how Microsoft evaluates the password that means it doesn’t work.

The Evaluation Process (or Why a Banned Password isn’t Actually Banned)

Potential passwords are evaluated through a 4 step process:

  1. Normalization
  2. Fuzzy match check
  3. Substring match check
  4. Final scoring

Step 1: Normalization

First, the password is converted to all lowercase. During this step all of the common leetspeak substitutions are also reversed (0=o, 3=e, 5=s, etc)

Step 2: Fuzzy Match Check

This normalized, all lowercase password is then checked against both banned password lists +/- 1 character, so if “abcde” is on the banned list then both “abcd” and “abcdef” are also considered banned.

Step 3: Substring Match Check

In addition to this, substring match is done to make sure the password does not contain the user’s first or last name or the tenant name. It should be noted however, that substring matching is only done for names that are over 4 characters long. You can breathe a sigh of relief Qui Gon Gin.

Step 4: Score Calulation

The final step is score calculation, and this is where the problem is. Every element of the potential new password is given a score, and added up. If the final score is 5 or more, the password is considered secure and will be accepted. Scores are given by the following:

  • Every banned word is given 1 point
  • Every other character that isn’t part of the banned word is given 1 point
  • If the password scores 5 or more, it is accepted.

In case you haven’t figured it out yet, this is exactly where the problem is. Banned words are not actually banned. They’re only slightly penalized. Any organization that is trying to increase their password security is going to follow at least some part of the NIST SP 800-53 rules (or the XKCD password comic for those of us who never bothered to get a CISSP) and require a minimum length on the password to be as long as we can to increase entropy and make the password harder to crack. However, if a banned word isn’t actually banned then you can get by on password length alone.

For example, let’s say your org is named “BlueOrg” and you have the word “blue”, and “org” in your custom banned password list, and your minimum password length is 14 characters. You then create a password that is BluePa$$w0rdorg71.

Blue = 1 point

Pa$$w0rd = 1 point

org = 1 point

7 = 1 point

1 = 1 point

17 character password totaling 5 points with 3 banned passwords in it. Any threat actor who is well versed in hashcat masks and has done a minimal amount of recon will break that password in about 30 seconds. I’ve seen it happen and I was able to verify it myself relatively simply.

Now obviously, nobody should be relying purely on Entra Password Protection as their only line of defense and it should be used in addition to the other two authentication methods (something you know, you are, you have) like MFA, and a biometric. However we should all be wary about implementing this system as it can under certain circumstances make an otherwise strong password, easier to crack.

Sources:

On-Prem Entra Password Protection for AD DS

Eliminate bad passwords using Entra Password Protection

This is fantastic work. Could you maybe add some docs links for the referenced items? I’d love to have those in here.

Also, would you be okay if we shared this broadly?

Thank you

The vast majority of the research is from Microsoft’s own documentation:

On-Prem Entra Password Protection for AD DS

Eliminate bad passwords using Entra Password Protection

It should be noted that at the very bottom of the second article, MS outlines this exact scenario:

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.

However, they don’t really offer a solution besides "Be careful, I guess? :man_shrugging: "

I’m more than happy for you to share this more broadly. I wrote it here under the hope that other people don’t fall into the same trap I did.