Organizations using Active Directory must update their password policies to block and detect compromised passwords, but comparing password monitoring vendors in this area can sometimes be challenging. Often, organizations are not sure how to compare vendors and are not sure what questions should be asked when working with password monitoring vendors.

By asking the right questions, you can pick the right partner and avoid introducing new technical, security, and compliance risks.

This document provides organizations using Active Directory with twenty questions to help find the right provider of password filtering and auditing tools for hardening enterprise passwords.

HERE ARE THE QUESTIONS TO ASK & WHY YOU NEED TO ASK THEM

#1 QUESTION: Does the provider specialize in compromised passwords or focus more on algorithmic rules for password complexity?

• REASON TO ASK #1: Current industry best practices put heavy emphasis on preventing compromised passwords and downplay algorithmic password policies that are the basis of older tools.

#2 QUESTION: Does the tool only check passwords on a periodic basis? (daily, weekly, etc.)

• REASON TO ASK #2: Some tools are designed for auditing passwords only after they’ve been saved. This results in users creating passwords that are vulnerable (insecure) and then being forced to change them (frustrating) until they find a good password.  NIST 800-63B is explicit that the password shall be screened at the time they are being established. And the source of the data should be continuously updated.

#3 QUESTION: Does the tool only check when a password is being created or reset?

• REASON TO ASK #3: Most tools focus on checking only when the password is saved. However, a password that was previously safe may no longer be. The concept of continuous monitoring was not required when a good password could be determined by algorithmic complexity alone. Note that continuous monitoring requires a blacklist to be updated regularly.

#4 QUESTION: Does the tool compare users’ new and previous passwords to determine if they are substantially different?

• REASON TO ASK #4: Even good passwords are vulnerable to hacking if they are too similar to users’ previous passwords. The FAQ from NIST 800-63B indicates that the research shows that “select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password.” Learn more about similar and expected passwords.

#5 QUESTION: Can the tool exclude the name of your company and possible variations that may not have been previously compromised?

• REASON TO ASK #5: NIST is clear that the organization shall be able to prevent the use of context-specific words and have fuzzy matching to cover possible variations. A custom password dictionary is a critical piece of password policy because it can block context-specific words like your company name or product name.

#6 QUESTION: Does the tool deploy a “Password Filter” object on the domain controller?

• REASON TO ASK #6: There are several ways to implement password screening. The Password Filter is how Microsoft supports password policy and change notification. It is the only method that works regardless of where the password is being changed.

#7 QUESTION: Has your Password Filter been signed by Microsoft?

• REASON TO ASK #7: If a provider has not had the Password Filter reviewed and approved by Microsoft, it will fail under certain security hardening configurations.

#8 QUESTION: Can the tool support NIST recommendations for eliminating periodic password reset?

• REASON TO ASK #8: Substantial research has shown that password expiration policies don’t improve security.  Therefore, NIST recommends NOT requiring passwords to be changed arbitrarily (e.g., periodically), but only if there are methods to immediately determine when a password is no longer safe. Many tools on the market can’t detect when a saved password becomes vulnerable later.

#9 QUESTION: Does the password database also include data from actual cracking dictionaries?

• REASON TO ASK #9: NIST 800-63B is explicit that passwords shall be screened against dictionary words, including common substitutions, transformations, and patterns. This can be obtained by including cracking dictionaries actually used by hackers, but some providers only include passwords that have actually appeared in a data breach.

#10 QUESTION: How frequently is the database of compromised password updated? (daily, monthly, quarterly, etc..)

• REASON TO ASK #10: Lists of compromised passwords will change every day as new data breaches occur. Attackers use the latest breach data, but many providers use blacklists that are rarely updated. They rely on free password sources rather than investing in keeping their data current.

#11 QUESTION: Does the tool use clear text data for screening passwords?

• REASON TO ASK #11: There are a variety of techniques for password screening, including options that avoid the inherent legal risk and security vulnerability of dealing with clear text password data.

#12 QUESTION: Is your compromised password database in a flat file or format that I can see?

• REASON TO ASK #12: If a password blacklist is maintained in a flat-file format, as the database becomes larger, you may find each check takes longer than you’d find acceptable.

#13 QUESTION: What are the automated remediation options available when a password is found to be compromised?

• REASON TO ASK #13: Automating the manual administrative tasks associated with password security can provide business value. However, not all tools offer sufficient automated remediation options.  For illustration, if requiring a user password reset, can you add a window of time for this to be completed, so it doesn’t result in the user being locked out.

#14 QUESTION: Does the tool require custom dictionary entries to be updated on each individual domain controller?

• REASON TO ASK #14: Understanding how the product will be maintained across your multiple domain controllers can indicate how difficult it will be for your administrators to use.

#15 QUESTION: Does password-checking always use a partial hash comparison?

• REASON TO ASK #15: Partial hash comparison (K-Anonymity) is an alternative to working with the clear text or hash of the full password and is essential to ensuring passwords cannot be reversed. 

#16 QUESTION: What client information is logged or stored at the provider?

• REASON TO ASK #16: Password screening should not require any client data to be stored by the provider.

#17 QUESTION: Does the provider have a written Information Security Policy that adheres to known secure coding best practices and requires third-party testing?

• REASON TO ASK #17: This type of software interacts with mission-critical systems that have the highest security implications.

#18 QUESTION: Is there a graphical user interface for installation and configuration?

• REASON TO ASK #18: Products that provide user interface are generally easier to manage for more staff members and with less training time required.

#19 QUESTION: Do they have enough people to continue to operate in case of a support emergency?

• REASON TO ASK #19: Software from 1 – 2 person companies can be risky if something unexpected happens.

#20 QUESTION: Does the organization have Errors & Omissions insurance and the other forms of insurance that our company requires?

• REASON TO ASK #20: Insurance may be the only financial recourse if a major problem technical, legal or security incident were to occur.