I have previously asked about the application of the NIST Special Publication 800-63-3 (password policy). Password Policy

Without a simple way to add a password blacklist to AD, what are the common strategies for implementing these recommendations ( https://pages.nist.gov/800-63-3/ ), in the real world? I am trying to rewrite the internal password policy but without this (what is seemingly an integral part) I'm not sure whether a hybrid policy would be better?

  • are you aware that MS released their own guidance document last year on this topic? – schroeder Sep 1 '17 at 9:40
  • @schroeder I was not aware of that, just searched and found the recommendations. Without the adoption of a password list in AD, would you advise waiting until that comes into play before altering policy? – Chri3 Sep 1 '17 at 9:47
  • When and if you alter policy depends on your goals and what risks you want to mitigate. I'm not sure that I would hold off on implementing the correct alignment of risk treatments in policy just because one feature was not available. – schroeder Sep 1 '17 at 10:34

Other strategies would not only be difficult to implement, they might be counter to the intent of NIST 800-63b. Fortunately, there are multiple blacklisting solutions, so you probably don't need (or want) another strategy.

Here's my reasoning.

First, to summarize from 800-63b, section 5.1, the portion about verifiers (such as passwords) that are directly applicable to checking the quality of the user's password.


  • Authenticators (passwords) must be:
    • Minimum 8 characters
  • Authenticators also checked against blacklist using "values known to be commonly-used, expected, or compromised" (the core of your question) - at least one of:

    • Passwords obtained from previous breach corpuses
    • Dictionary words
    • Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’)
    • Context-specific words, such as the name of the service, the username, and derivatives thereof
  • If found in blacklist:
    • advise the subscriber that they need to select a different secret
    • provide the reason for rejection
    • require the subscriber to choose a different value

By my reading, the intent of 800-63b section 5.1 appears to be:

  • Prevent users from using blacklisted passwords in the first place

  • Train the user to understand why the password choices were poor

If this isn't possible via the password-changing interface directly, other strategies would require imposition of those goals via human policy. This would require:

  • A separate way for users to look up passwords in the blacklist. Since the Windows password-changing interface is dedicated and isolated by design, providing a digital way to do this would be tricky (and printing a book instead would be a usability and maintainability nightmare!)

  • A way to audit for compliance after the fact (by cracking the passwords using the blacklist as a dictionary). You should be doing this anyway ... but in this case, I believe that it defeats the purpose of the NIST guidance (to ensure that the blacklisted passwords are never used in the first place)

Fortunately, you don't need another strategy, if you only need to do the following:

In other words, alternate strategies are not only not needed -- they would be impractical, provide a difficult user experience ... and may not actually be defensibly conformant.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.