How-To

Eliminating Bad Passwords

Paul Schnackenburg looks at the issue with passwords and different attacks, modern approaches to password policies and management and how you can improve your (Office 365) organization's security posture with just a few clicks by banning bad passwords.

• By Paul Schnackenburg
• 08/05/2020

Despite valiant efforts from the tech giants to move the world of IT away from usernames and passwords toward better authentication options, the good bad old password is going to be with us for a long time yet.

Because "identity is the new firewall," this is problematic, and doubly so in the current situation as most staff are working outside of the protection of corporate firewalls and other security controls. If you doubt this, look at any recent high-profile data breach in the news -- in most cases the initial foothold is traced back to a compromised user identity. The infosec industry tends to be focused on complex solutions to specific situations, but you can vastly improve your business's security posture by taking care of the basics first: multi-factor authentication (MFA); passwords and identity protection; patching; and user training.

This article will look at the issue with passwords and different attacks, modern approaches to password policies and management and how you can improve your (Office 365) organization's security posture with just a few clicks by banning bad passwords.

The Problem with P@$$words
There are a few main issues with passwords -- one is that the rules around their management that we've been enforcing for decades are resulting in bad passwords. Another is that because they're so fundamental to modern life, people have so many that they re-use them across different services.

The focus on the length and complexity takes away from the reality that for many attacks, having the best password in the world will not save you.

A common attack is credential stuffing where criminals buy lists of usernames and passwords from data breaches and then try those on other services, which will often work due to users using the same password across different services. In this case the attackers have the password, so length and complexity are immaterial.

Phishing is another common vector, where the user is handing over their fantastic password to the criminal on a fake login page. Password spray is another attack that's hard to defend against, where the criminals use a list of common passwords across a list of all your users, trying them slowly to make it hard for defenders to see the attack in the noise of the logs of normal authentications. It might help if you have an uncommon password, but the likelihood that someone in your business is using Password1 or qwerty is high.

There are a few other less common attacks such as keystroke logging, local discovery and extortion -- and again, in all those attacks, a complex password won't save you.

The one attack where your password quality matters (a little bit) is brute force, where an attacker steals the AD (or other credential) database and then uses some form of cracking rig to extract the plain-text passwords. First, understand that most of the attacks above are easier to do and offers quicker returns so it's unlikely that most attackers will even bother with brute force. If they do, modern hardware makes password complexity (mostly) irrelevant, unless it's a very long password.

The solutions for businesses are simple (but not necessarily easy) -- first complement the password with MFA, free for all license tiers of Office 365, and second, ban bad passwords.

For individuals, with some basic tech skills, the best solution is a password manager such as 1Password, LastPass and others. I have been using LastPass for years, and all admin access to my clients is protected with Azure AD MFA.

• Minimum 8 characters
• Maximum at least 64 characters
• Options to use special characters but don't enforce them
• Restrict context specific and commonly used passwords (see below)
• Restrict passwords obtained from previous breach data

And don't force users to change passwords regularly, it just leads to the same password with a different number/month at the end.

Banning Bad Passwords
If you're a Global Administrator for your Office/Microsoft 365 tenant, head over to the Azure AD portal, click the Security link and then Authentication methods.

Click Password protection, where you can configure smart lockout which will lock an account after 10 wrong password attempts (by default) and stay locked for 60 seconds. The "smart" bit is that if the wrong password is entered once after the lockout, it'll lock again, and then progressively increase the time that the account is locked with each wrong attempt.

Microsoft maintains a list of common passwords that are banned automatically for cloud user accounts -- users whose accounts were created directly in AAD. The specific passwords on it are secret, but it contains about 2,000 common passwords.

If you have Azure AD Premium P1/P2 (or a trial license), you should augment this list with words common to your user population ("context specific" in NIST terms). Sports teams, city landmarks, products, acronyms and brand names in your business/region should all be added, up to 1,000.

The process for evaluating a new user password goes through two phases. First it's normalized with all uppercase characters converted to lowercase and all common character substitutions are changed back. For instance, P@$$w0rd will be changed to password. This normalized password is then compared to the global (and custom when you've configured it) banned list using fuzzy matching.

As an example, the password abcdef is rejected and if the user tries abcdeg or abcdefg instead they will also be rejected because they're too close -- within one edit distance -- to the banned password. The password is also checked for the user's first and last name, and finally a scoring system checks to see if a longer password that contains banned words is sufficiently complex.

For instance, the password ExpertIT@bcdef42 is normalized to expertitabcdef42 with ExpertIT being banned (tenant name) and abcdef also banned leading to a score of 4 (one for each banned word, plus one for each number), which is less than 5, leading to a rejected password. Read more here.

That's great, you say, but my organization relies on Active Directory (as does 90 percent of businesses) on-premises and our passwords are set on-premises and then synchronized to the cloud. Fear not, Microsoft has a solution for this as well.

Password Protection for a Hybrid World
Azure AD Password Protection for Active Directory Domain Services (say that five times quickly in a row) uses the same lists as above to do the same for password changes and resets against your on-premises AD Domain Controllers (DC). It doesn't require any network ports to be opened, no AD schema changes, the clear-text password never leaves the DC and your DCs don't need internet connectivity. There's no minimum domain or forest functional level, although the DCs that you deploy the agent to have to be Windows Server 2012 or later. And you must have migrated your DCs to use DFSR for replication.

There are two components: a proxy agent that communicates with Azure AD, and a DC agent that's installed on each DC. You can do a partial deployment for a pilot by installing the agent on a subset of your DCs as long as you understand the limitation. For example, if someone is changing their password against a DC without the agent, a bad password won't be blocked.

If you're feeling a bit insecure (no pun intended) about installing agents on your DCs, and member servers, and potentially frustrating users trying to reset their passwords, the default and best mode to start with is Audit mode, where bad passwords aren't blocked but the attempts are logged in the Event log, enabling you to build a case for switching to Enforcement mode.

Install the Azure AD Password Protection proxy service agent on at least two member servers and configure it using the supplied PowerShell module (Import-Module AzureADPasswordProtection), with the cmdlet Register-AzureADPasswordProtectionProxy. This is followed by registering the on-premises forest with Register-AzureADPasswordProtectionForest cmdlet. No restart is required after this installation.

Then install the DC agent on each DC. Note that this does require a restart (to enable the password filter DLL) but you can delay the restart to a time suitable to you change window with the /norestart flag. For nuances to the deployments (on Server Core servers or with MFA protected accounts for instance), see the full documentation here.

Beyond Passwords
Ultimately the solution to the security risks and hassles with passwords is to get rid of them altogether, and Microsoft has outlined a roadmap to help businesses get there. It's a long road, and it's going to take time, but I can see a future where the identity directory doesn't contain any passwords at all and every user authentication is performed using biometrics, authenticator apps or FIDO2 security keys.

I wish you good luck on your quest to improve your user's password hygiene and eventually rid the world of passwords altogether.