Password Filters

By: Itamar Hoshmand - Chief Security Architect & Software Expert   |   Updated: 8/12/2021

Weak passwords are one of the leading vulnerabilities that expose organizations to cyber incidents. Each organization must assume that a part of its users has weak passwords – ones that could be hacked in less than a second.

"P@assw0rd", "Aa123456"," Letmein123", "Qwertyuiop1", "Iloveyou5" are all examples of weak passwords that can be found in the top 100 most common passwords. Most organizations have a basic GPO policy that prevents these passwords. A minimum of 12-character password length is a good way for lowering password cracker's success, though most organizations wouldn't be thrilled to choose 12 over the standard 7-8 characters because average users tend to forget their passwords more often.

An adversary that targets a specific organization or user may use brute force or dictionary attacks while hacking. However, combining it with some social engineering could improve the attacker's probability of success. For example - combining the employee's child's name with his birthday followed by an exclamation mark is one example that could improve an adversary's success.

There is a common understanding nowadays that user passwords are the gateway to all organization's computer networks. And yet, recommended passwords policies aren't being enforced because of the complexities that arise from the available solutions and user requirements.

A relatively short password will continue to be used in many organizations. In these cases, in particular, the passwords should be unique, complex, and rich to protect against password cracking. All trivial and common passwords should be avoided.

Domain Controllers (DC) servers – are the servers that respond to security authentication requests and set the security policies for the entire Domain. It may seem trivial that these machines will excel in providing passwords complexity policies. And yet – compromised-passwords hacking holds the lion's share of all data breaches.

Active Directory is configured with a default domain password policy. This policy defines the password requirements for Active Directory user accounts, such as password length, age, etc.

A fine-grained password policy can be applied using a Password Settings Object (PSO). An administrator can create many PSOs and apply them to a User or a Group. Figure 1 presents the PSO properties that can be configured and be used for setting the password policy.

(Figure 1 :Password Settings Object (PSO) properties)

Most of the PSO's properties are self-explanatory, but I would like to shine a spotlight on the important information:

When "Password must meet complexity requirements" is applied, a password must meet these requirements:

1. Not contain the user's account name or parts of the user's full name that exceed two consecutive characters
2. Be at least six characters in length
3. Contain characters from three of the following four categories:

• English uppercase characters (A through Z)
• English lowercase characters (a through z)
• Base 10 digits (0 through 9)
• Non-alphabetic characters (for example, !, $, #, %)

This is a start, but a user constrained to this PSO will be allowed to set trivial and common passwords: Aa123456, Qwerty7, Password1, P@ssw0rd, etc.

When using these passwords, an adversary who uses Brute Force may guess the password using repetitive or iterative mechanisms. Crackers use many techniques to find these loopholes – they bypass the account lockout policy by Password-Spraying once or twice an hour. Give them six months of patience using Dictionary Injection, and they will guess your password. Common passwords can be recognized by their hash – they are simply present in the Hash Rainbow Table, so an attacker that performs a memory dump will soon gain higher privileges. Exploring Mitre Att&ck can yield many sub techniques and real-life breaches that could be avoided.

What is missing?

 The answer to that depends on many factors, but each organization should have the ability to set its own password complexity using these additional features:

1. Blacklists – each organization should exclude a different set of words from its passwords. The organization name is a good blacklist candidate, to avoid Google123 passwords for a google employee
2. Key repetitions – the ability to ban passwords such as AAAbbbccc5
3. Adjacent keys – the ability to ban passwords such as Qwerty123
4. Consequential keys – the ability to ban passwords such as Abcdef123

Everything discussed above shines ample light both on positive and negative aspects.

 The negative: DC's functionality for passwords complexity and policies aren't good enough. If they were, password cracking wouldn't be among the leading hacking methods. Each organization today may find "dumb" passwords in use. 

 The positive: OK, we might make considerable progress when we understand that using a complex password (as a first step) should be a fact of life.

 Using and relying on Multi-Factor Authentication (MFA) solutions might seem enough. But it isn't. There are always applicative users that must work without MFA - MFA in a domain environment can be found in a secure or isolated environment where zero trust technologies are used. Still, usually, it isn't used in most environments.

 Even more important is the holistic approach to security - Security is built in layers. Each layer is a single part of a greater whole but must itself be bulletproof and not rely on other layers. We wouldn't want our hand-brake system in the car to not completely stop the vehicle and rely on the gears for its role.

The next step is to find a solution to ban weak passwords. How do we do it? We don't have the right tool for the job because the DC can't be the sole cure for this ailment. Thankfully Microsoft architects allow custom Password Filters to be added to their system. Password filters provide a way for you to implement password policy and password change notifications. 

Implementing and integrating a password filter may be the first step towards a world full of strong and complex passwords; There is a solution. This solution also has a name and even several open-source libraries running around.

 But the reality is not that simple, in my opinion. Implementing a Password Filter requires an understanding of Windows driver development, which itself runs in CRT mode in the operating system and thus doesn't offer all the handy Windows API while working with Unicode Strings. Moreover, a password filter is a program that is loaded on system boot and terminated together with the operating system. Any memory leakage or resources abuse can be fatal. There are many other coding considerations and practices that must be followed to avoid creating a new vulnerability.

For me, it's not right that an amateur programmer will implement his own Password Filter. And even worse – that he will be brave enough to install it on a DC server, integrated into the operating system.

There are many easy mistakes/bugs to implement that might crash a DC machine or even produce other security vulnerabilities. Some are documented, and some aren't. To avoid all these pitfalls – be sure to put your best programmers on the job, and then you should carefully review their work.

There are many other relevant considerations that are outside the scope of this post, but I'll list them here just to raise awareness: loggings, configuration, installation, version management, build systems, open-source licenses management, machine architectures, operating system versions upgrades, and many more.

In conclusion - passwords complexity must be firmly enforced. The solution is a Password Filter, but due to its serious consequences and the underlying challenges – this project must be implemented by a professional programmer.

Back