What is a one sentence summary of your feature request?
Expansion of dictionary functionality
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
During our last penetration test, an attempt was made to crack the hashes of AD passwords. Despite complexity settings and a minimum length of 14 characters, this succeeded in several cases. The longest cracked password was 22 characters long. It was a long word from the dictionary, combined with digits and special characters. Passwords containing multiple first names (presumably of children, etc.) along with extra characters were also cracked. The penetration testers also had variations using leetspeak ready to go.
Upon inquiry, I learned that this was accomplished through dictionary attacks in a wide variety of variations.
To mitigate exactly this type of attack, the Password Policy Enforcer would need to expand its dictionary functionality.
Providing dictionaries (German, English, and possibly additional languages such as French or Spanish). I’m thinking of something like Merriam-Webster in the US or an equivalent. First names are generally included in major online dictionaries.
Providing leetspeak logic to also check common substitutions across all words
Calculating password entropy and allowing the definition of a minimum threshold. This would let users choose between a short, complex password or a long password with less complexity.
Integrating the Weakpass API (Swagger UI) could potentially help as well.
A few examples of passwords that were cracked:
Spektralphotometer01
Aufenthaltsgenehmigung1978
!Amsterdam2020
Ktm1290superduke
BorussiaDortmund09#
Freestyle2701!
Gewindekennung75
LaraDaniel20201
Soeinschmarn!!
Marie-Christina10!
Pr1d30fl0nd0n!
How do you currently solve the challenges you have by not having this feature?
We are looking into competing products. We are also working on raising awareness among our employees.
Hi @DerOTTO . Thanks for taking the time to give us your feedback. I checked your sample passwords against a typical dictionary rule configuration, and it rejected all these passwords. Here are the passwords along with the matched dictionary words:
Spektralphotometer01 RALPH Aufenthaltsgenehmigung1978 HALTS !Amsterdam2020 AMSTER Ktm1290superduke SUPER BorussiaDortmund09# BORUS Freestyle2701! FREES Gewindekennung75 WINDE LaraDaniel20201 ADANI Soeinschmarn!! MARNI Marie-Christina10! MARIE Pr1d30fl0nd0n! PRIDE
This is with a tolerance of four and non-alpha character and character substitution enabled.
Admittedly, a tolerance of four may be a little too restrictive in your situation. Even with tolerance set to 9, Spektralphotometer01 still matched with PHOTOMETER. I did not check the other passwords with higher tolerances.
Can you please tell us how your rule is configured, and whether or not you have the passphrase filter enabled (Passphrase tab in the policy), and if so, how it is configured? If you would rather not share your configuration publicly, then please open a support ticket at https://customer.netwrix.com/sign_in.html?rf=tickets.html and we will help you to work out why these passwords weren’t rejected by PPE.
We will also review your suggestions for a future version.
We are not a customer but we are searching a fitting solution. We had have a demo a few days ago and it was told to us that no dictionary is delivered. The dictionary function is thought for company specific terms only.
Furthermore the dictionary words you delivered according to our passwords do fit, but also block many passwords at all and it would be aweful for users to find an allowed password I think. Ideally the recognition is a bit more fitting to the real word or combination.
The dictionary rules sound interesting in general. Do you have more information about this feature?
There is definitely a dictionary file included with PPE, so there must be a misunderstanding there. I will check internally to make sure we are giving out the right information. You can also make your own (or download one).
Yes, a tolerance of four is most likely too strict for your environment. The tolerance is one of the ways to fine-tune some of the rules in PPE. Increase the tolerance to make it more tolerant of partial matches, or decrease it to make it less tolerant. There is no perfect value. Like many security decisions, it is a balance between security and useability.
If you can, please download and install PPE onto a test computer or VM. It doesn’t need to be a DC, and you don’t need to install all of PPE. Just the management console so that you can experiment with different settings (primarily the tolerance to start with). You can then configure the dictionary rule and experiment with it in the Test Policies page (Test Policy | Netwrix Product Documentation).If you can’t find a balance that works for you, then let us know and we will suggest more advanced options based on your findings. Give us some examples of passwords that should be accepted and some that should be rejected.
The page linked above also has instructions on how to run the Bulk Password Test. You can feed your complete list of failed passwords from the audit into it to see how many of them PPE would reject with the current settings. You can get it to zero, but that may be too restrictive for you (back to finding the right balance).
The dictionary rules, are two rules in each PPE policy. You normally only need to use one, but having two allows us to have more advanced configurations and possibly different files. It is one of the ways we can fine-tune PPE to meet different needs. You can read more about them at Dictionary Rule | Netwrix Product Documentation