How to implement password policies using business rules modeling

info@mhaller.de (Mike Haller) — Sat, 29 May 2010 13:34:46 +0200

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.

Continue reading "How to implement password policies using business rules modeling"

Our score at The Joel Test

info@mhaller.de (Mike Haller) — Sun, 18 Apr 2010 19:19:00 +0200

How does my company/my team score at The Joel Test?

Let's see...
1. Do you use source control? YES
2. Can you make a build in one step? YES for most products, NO for others.
3. Do you make daily builds? YES
4. Do you have a bug database? YES
5. Do you fix bugs before writing new code? NO
6. Do you have an up-to-date schedule? NO. Either it changes too often, or stuff gets moved, or we're behind the schedule because we forgot something to do.
7. Do you have a spec? NO
8. Do programmers have quiet working conditions? NO. Coders interrupt each other very often.
9. Do you use the best tools money can buy? NO. The only good commercial tools are PL/SQL Developer and JProfiler. All others are open-source or other free tools with bad usability or incomplete integration (e.g. The Gimp, M2Eclipse)
10. Do you have testers? NO
11. Do new candidates write code during their interview? NO
12. Do you do hallway usability testing? NO. Occasionally we do, with at most 1 other "user".

Final score: 4/12

According to Joel, that's above average, but still too bad. We'll have to work on that.

The things i'm going to change next:
5) - fixing existing/known bugs before writing new code/new features.
2) - making all our high-level builds automated, not only single artifacts.

What concerns me most is point 7), although I haven't got a clear idea why and how to write a spec for something which is already being built. The current plan is to use the user's manual and developer's manual, extract abstract information and then detail it out into an architectural overview documentation.

Mike`s Blog - Work

How to implement password policies using business rules modeling

Our score at The Joel Test