Enterprise password policies are meant to make organizations more secure. However, anyone who has spent time dumping Active Directory passwords and cracking them knows there has been a fatal flaw in our password policies. The good news is NIST and Microsoft have finally discovered the flaw that Pentesters have known for years! Now that NIST has recognized and updated its guidance on passwords, we can fix our password policies and stay within best practices and compliance.

Short on time? TLDR

Password Policy Weakness

You might already know the weakness within enterprise password policies. Think about the most annoying aspect of your organization’s password policies. Did the 90-day password change requirement come to mind? Consider what you do when arbitrarily forced to change your password. Do you create an entirely new password or just slightly alter your old password? If you just slightly alter your old password, you are not alone. Turns out that if you ask people every 90-days to come up with a new, long, and memorable password that they have to use daily, they will start to use a predictable pattern when building passwords.

Microsoft Password Policy Recommendations as of October 2022

Microsoft updated its password guidance in October 2022, recognizing the issue with arbitrary password rules. The rules themself make sense and do help password strength, but not when the rules pair with the human element. When paired with the human element, each imposed password rule will have an inverse effect of weakening a password.

Many valid password practices fail in the face of natural human behaviors. Understanding human nature is critical because research shows that almost every rule you impose on your users will result in a weakening of password quality. Length requirements, special character requirements, and password change requirements all result in normalization of passwords, which makes it easier for attackers to guess or crack passwords.

learn.microsoft.com

The same policy guidance outright states, “Don’t require mandatory periodic password resets for user accounts.” Microsoft’s stance is clear, no more mandatory password resets. However, what is NIST’s guidance on this topic?

NIST Password Guidelines 2022

Along with Microsoft, NIST also concludes that our ideology around passwords needs to change. The recently updated “NIST Special Publication 800-63B” includes the following passage. Side note, NIST documents refer to “passwords” as “secrets.”

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

NIST 800-63B – Section 5.1.1.2 Memorized Secret Verifiers – Page 14

What To Do Before Changing Your Password Policy

So we have the backing of two major policy advisors in the industry(Microsoft and NIST) to eliminate our 90-day password change requirement. Well, not so fast. We have a few prerequisites before we alter our policy. While some password rules can now be removed, new rules must be applied first. In a sense, we are shifting the security burden from the end-users to Security and Domain Administrators.

Before removing old password policy rules, we need to have the following safeguards in the new policy framework. Those new requirements are as follows.

• Require Multi-Factor Authentication(MFA).
• Increase the minimum length of passwords to 14 characters.
• Screen for passwords obtained from previous breaches.
• Screen for dictionary words, and repetitive or sequential characters (e.g., ‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of the service, the username, and the derivative thereof.

The above requirements seem daunting initially, but some tools can help us. Through Azure AD-Link and Office 365, the MFA requirement is simple to fulfill. Also, the password minimum length increase is easy to update via Group Policy. The rest of the requirements are screening for weak and breached passwords. These will be a little more difficult, but I have a solution!

Screening for Weak or Breached Passwords

We can screen for weak and breached passwords using a well-known tool and a highly reputable data source. We will use the PowerShell module, DSInternals, a collection of tools to better secure Active Directory. Along with DSInternals, we need a source of breached passwords to look for. Troy Hunt’s service, “Have I Been Pwned“, provides a simple database of breached passwords in NTLM hash format. This breached password database is updated yearly with new data.

Combining DSInternals with the “Have I Been Pwned” database is a simple process but does require about 28GB of hard drive storage. The DSInternals tool is well-vetted and is available on the Microsoft-operated site “PowerShellGallery.com.” To install DSInternals open an administrator PowerShell console on the system that will be used to audit Active Directory and run the following command.

Install-Module DSInternals -Force

That is it for the DSInternals install. If you have an issue with it, check out the DSInternals GitHub page for troubleshooting steps. Next, we need the “Have I Been Pwned” database. Download the “Have I Been Pwned” database by opening the URL below and downloading the “NTLM Hashes ordered by hash” either via CloudFlare or Torrent.

URL: https://haveibeenpwned.com/Passwords

Once you have downloaded the compressed database, move the file to the same server you installed DSInternals on. When the transfer completes, extract the compressed text file. This uncompressed text file is what we will use with DSInternals.

Once you have the uncompressed text database of breached passwords, run the following commands.

# Using DCSync, build a object with all Active Directory account data.
$ADAccounts = Get-ADReplAccount -All -Server dc01.testdomain.com

# Pipe the AD account data to the password testing script.
 $ADAccounts | Test-PasswordQuality -WeakPasswordHashesFile "C:\pwned-passwords-ntlm-ordered-by-count-v8.txt"

The output will include user accounts with breached passwords and accounts with other security issues. This process can be scripted and automated to quickly catch weak and breached passwords. That same script could email the user and force them to do a password update. I plan to script this process out and will post it in a future blog post.

Set up Alerting for New Password Breaches

“Have I Been Pwned” provides an alerting service when any email account with your company’s domain name is found in a data breach. You will need to go through a verification process to prove ownership of the domain. After verifying your domain, you will get a list of existing breached accounts. Your company will now be notified of any future breaches.

URL: https://haveibeenpwned.com/DomainSearch

Don’t forget to establish a password breach incident response plan, so your team is ready to respond if a breach occurs.

Wrap-Up; TLDR

The newly accepted password ideology allows us to tune our policies to better fit human behavior. Removing 90-day or arbitrarily periodic password updates will allow users to use a longer password that they can better remember. However, before doing so, we need to add monitoring for weak and breached passwords. Use the following tools to cover the new requirements and drop periodic password updates.

• PowerShell Module DSInternals to find weak passwords.
• Download the “Have I Been Pwned” password database and pair it with DSInternals.
• Sign up for the “Have I Been Pwned” domain breach alerting emailing list.

As a final note, these technical controls are good, but end-user training is still the most valuable preventative control. The password policy change is a good time to explain the change to end-users and how to properly build good passwords.