How to implement password policies using business rules modeling

We all know that passwords ought to be strong - strong enough to withstand common attack vectors, such as brute-force dictionary attacks or plain guessing. Most software systems with identity management also incorporate some kind of password policy enforcement and their configuration options (here, here, here and here).

There are even commercial standalone tools focusing on enforcing password policies. For example, the Password Policy Enforcer by Anixis or Specops Password Policy. Many of these products enable administrators to define policies and configure rules to prevent users from chosing weak passwords and comply to corporate security policies.

In this blog post, I'd like to show the principle steps in implementing a password policy enforcement component using flow rules, decisions and scoring (bonuses and penalties) to calculate the strength of a given password using Visual Rules. In contrast to commercial tools, which often already integrate with domain controllers, this example only shows the rules, not how it could be integrated into the Windows domain or into a web application.
What are the advantages?
Implementing enforcement rules as a separate component using a business rules engine has some advantages, as it helps ...

• ... users to improve security by giving feedback about the strength of their chosen password.


• ... enterprises to improve security by enforcing password policies for their critical systems and to consolidate different policies of various systems into one single rule set.


• ... developers to implement password policies in a standardized way and to be able to quickly add new rules or remove conflicting rules.


• ... architects to gain more flexibility when requirements change, for example when new systems with additional policies are incorporated into the system landscape.


• ... administrators to dynamically update password policies ad-hoc, being able to make up their own fine-grained rules if needed, or add special cases.


• ... support staff while troubleshooting, e.g. to identify problems with user account registrations by improving the transparency of policies and thus improving the user experience.


• ... security personnel to monitor overall (e.g. enterprise-wide) password quality.

How does it work in general?
- Receiving a plain-text password
- Parse the password, analyzing properties such as length, occurrences of characters
- Analysis of the password in regard to known anti-patterns, such as repetitions or the use of numbers at the end
- Validating against a dictionary to prevent brute-force dictionary attacks
- Scoring the strength of the password bases on the parsing data and analysis step
- Mapping to a human-readable strength level (e.g. Weak, Good, Strong)
- Verifying minimal requirements, aborting processes such as user account registrations when password policies are not met (policy enforcement)

Okay, let's model an example. The first thing after starting the Visual Rules Modeller is to create a new project. I'll call it "Password Policy".



The first task in modeling is to create a new flow rule "Scoring" and draft the overall steps involved in calculating the password complexity and strength scoring. The three steps i have identified above are:
- Count occurrences of characters, numbers and special characters (symbols)
- Analyse their positions (beginning or at the end of the password)
- Calculate a score and map the score to a strength level.

Parsing of the password and extracting information about the characters, numbers and symbols is a bit technical, but once done, the results and rules can be reused and easily extended when new information is needed. The parsing will count the characters, numbers and symbols individually. I will begin by modeling a datatype Occurrences which will hold this data:



A loop will iterate over each character in the password. Each character is tested for being either a number, a symbol or an alphanumeric character. For each of those categories, a separate counter is increment on the Occurrences object.



The screenshot only shows the descriptions (to save screen space). The code actually looks like this:



The next part is the analysis of the password, its characters and the positions of the characters in the password. This information will later help to identify anti-patterns such as passwords ending in with numbers. For this, i will also model a datatype Positions which contains the results of the analysis: the minimum and maximum positions where a character was found in the password. The attributes numbers and symbols are actually lists of all positions as an intermediate variable.



The flow rule which calculcates this information looks similar to the one which counts the flow rules, except for the post-processing step where the positions are aggregated and only the minima and maxima values are kept.





The second last thing to do is to calculate the scoring of the password based on the information we have gathered during counting occurrences and determining positions. This is the place where rules come into play: the check for minimum values and assign a score bonus or a score penalty when conditions are met or not met. In the following example, the Scoring rule model checks whether the given password meets the minimal length criteria. if it does, a bonus is assigned to the score. If it does not, the score is decreased with a penalty.



So, how about adding new scoring rules for, let's say, the use of lower-case characters? Easy:



Finally, we map the calculated score to a human-readable complexity level using a Decision Table.



Let's test the password policy rules using test cases. This way, we will also see the results immediately.



After running the test cases, the rules show statistics. This is nice to see how often certain conditions are met and if the rules actually are fired.



And of course it also works for the score-to-level mapping:




The fun thing about implementing password policies as rules is that the rule set can be reused. They could be published as a service in a SOA landscape, they can be integrated into (web) applications or even serve reporting.

As you can see in the statistics, it would also be a nice basis for reports on the current level of password strength in the user database. When such rules are implemented in the corporate password management system, they can easily track these statistics and provide indicators to administrators or security personnel whether their users need to informed about using stronger passwords.


Disclaimer: I work for Innovations, the vendor of Visual Rules.

• Comment (1)
• Trackbacks (0)