Practical Protection: Banning Bad Passwords 

Public Service Announcement

First, a public service announcement. (No, not this one.) I wrote about the problem of token theft earlier this year, and since then, there have been several breaches involving Okta, where apparently an unknown set of attackers were able to compromise Okta’s support tool and steal tokens from HAR files submitted by customers. Affected customers include 1Password and BeyondTrust, both of whom caught the attacks earlier… but there are very possibly others. Microsoft’s Merrill Fernando posted a good explanation of the issues surrounding token theft from HAR files, and he gives some practical advice on how to minimize the risk that this attack will be used against you. It is well worth reading.  

Now, on to this week’s topic: banning bad passwords from use in your Entra ID tenant. My Halloween column last year was about why reusable passwords are bad, so I thought I’d continue the theme this year and talk about what you can do about them, besides moving to passkeys or other technologies that do away with passwords altogether. 

The Problem(s) with Passwords 

There are too many problems with passwords to recap them all here. The one I want to focus on in this column is weak or reused passwords. Weak passwords are vulnerable to dictionary attacks, and reused passwords can be used in credential stuffing attacks, such as the one that apparently burned genetic-testing firm 23andMe. The old-school solution to this problem was to create “stronger” passwords. I put “stronger” in quotes because the common belief is that adding complexity to a password makes it harder to guess. That’s not technically incorrect, but it’s more correct to say that adding randomness to a password makes it harder to guess—just changing your password from “Password123” to “P@ssw0rd123!@#” doesn’t actually make things much harder for an attacker, plus it increases the chances that users will either forget the complex string (and thus be tempted to write it down) or that they’ll think it’s such a great password that they use it in multiple places. 

Accordingly, Microsoft’s password recommendations now call for a simpler approach, but backed by other technologies, including MFA. I talk a lot about MFA here, but that’s because it’s an important and underused technology. In this column, I want to mention another recommendation Microsoft gives: “Ban common passwords, to keep the most vulnerable passwords out of your system.” 

How Password Banning Works 

When a user makes a password change, Microsoft checks the proposed new password for weakness using several basic criteria. The first question is whether the password meets the built-in complexity restrictions. Other questions follow:  Does it contain some easily guessable substring like the user’s first or last name? Does it follow a predictable pattern like abcdef123? Is it the same as a recently-used password? Assuming the password clears these checks, its hash is calculated and stored and then it’s available for use. 

The Microsoft Entra Password Protection feature is a native part of Entra ID and its basic functionality is available to all tenants, although there are some additional capabilities for customers who have Entra ID P1 or P2 licenses. When a user tries a password change, here’s what happens: 

1. The password is normalized: it’s converted to lowercase and common substitutions (such as using “@” instead of “a”) are applied. 

2. The normalized password is checked against the Entra global list of banned passwords. This list contains easily-guessable strings (like the ever-popular password123) as well as common dictionary words from popular languages. Microsoft notes that they don’t publish the contents of this list because it would be easy for attackers to use it to find passwords that aren’t on the banned password list. 

3. If you have Entra ID P1 or P2, the normalized password is checked against your own tenant-specific list of banned passwords. The intent behind this feature is to let you add things like brand or product names or internal terms. For example, at Keepit, we call our employees “Keepers,” so “Keepit” and “Keeper” are both on our tenant-specific banned list.  

4. If the password has passed steps 2 and 3, it’s accepted. 

These steps are the same whether you have a cloud-only or a hybrid environment. However, password filtering for on-prem AD requires the Entra ID P1/P2 license but also that you install an agent on each AD domain controller in your forest. 

There are a few interesting nuances that deserve special mention. First is that the global banned password list also contains passwords added by Microsoft based on security telemetry. Services such as the excellent HaveIBeenPwned provide API-level access to banned password lists, too, but Microsoft’s list is only based on their own telemetry, not on the contents of password lists from other data breaches. Second, steps 2 and 3 perform fuzzy matches, so they’ll catch common pattern changes. For example, if you have “Contoso” on your banned list, “C0ntoso” will be banned but so will “Contpso” (because it’s only one character different than the banned original). The fuzzy matching includes matching the user’s first and last name, and, in cloud environments, the Microsoft 365 tenant name. 

If you Can’t Eliminate Them, Make Them Stronger 

The Entra Password Protection feature does exactly what its name implies: it doesn’t guarantee protection against all attacks, but it adds a higher degree of security to passwords, and, assuming you’re stuck with using passwords and can’t ditch them, it’s a valuable addition to your security toolbox.