Getting started with Lithnet Password Protection - Part 2 - Blocking common and context-specific passwords
In part 1, we saw how Lithnet Password Protection for Active Directory (LPP) allows us to test incoming password changes for exact matches against known compromised passwords.
Well, what if we want to prevent paswords based on certain words? Most users understandably want a password that is easy to remember, but in many cases, they end up choosing a well known 'password pattern' that can easily fall to brute force attacks.
A common password pattern I have seen is where a user combines a season with the current year, for example Winter2018 or Summer2017. Now, while this and previous year's versions of these passwords are in HIBP, future ones may not be. We can prevent the use of all passwords based on these words, by using the banned word functionality of LPP.
Banned words checks work a bit differently to compromised password checks. The compromised password check looks for an exact match in the store against the incoming password. The banned word check first normalizes the password, through a process that removes common patterns and character substitutions before performing the comparison. This allows us to determine if a password is based on a banned word, and prevent its use.
In order to use this functionality, we first need to enable banned word checking. In the group policy we created in part 1, enable the policy Reject normalized passwords found in the banned password store, and run gpupdate on the server with LPP installed to update the policy.
We can now add banned words to our store using the Add-BannedWord cmdlet. Simply add the base word (such as 'winter'), and then all passwords based on that word will be rejected with the code "BannedNormalizedWord"
NIST's updated 2018 password guidelines recommends that we block users from selecting context-specific passwords, that is, those based on the service, web site, or organization the password is for. After auditing my own users, I was surprised to see how many users we had base a password on the organization's name. We can prevent that by adding our company name as a banned word.
The normalization process isn't designed to prevent every single possible variation of a word that a user may select. It's designed based on real-world patterns people most commonly use to contruct these types of passwords. Our users may think they are being clever by swapping out o's for zeros and i's for ones, but hackers know these patterns all too well, and they offer little to no additional resistance against brute force attacks on passwords.
If you want to prevent users from choosing passwords based on dictionary words, then import the entire dictionary into the banned word store! The Import-BannedWords cmdlet will import a file of plain-text words (one per line) into the banned word store. This will mean your users will need to be thinking about using pass phrases. Single dictionary words, even appended with a few symbols or numbers will no longer work.
You'll once again need to think about how you communicate these requirements to your users, and make sure you password change pages have this information on them. Remember, all Active Directory will tell them is "the password does not meeting the password policy requirements". You'll need to find the balance between security and usability that is right for your organization.
Comments