Manage Learn to apply best practices and optimize your operations.

How to enforce password complexity

Rather than embed code in an application to address password complexity, Ed Tittel suggests developers create a component that's used whenever and wherever passwords are needed.

Those who've worked in the Windows environment for any length of time know that password complexity requirements first appeared in updates to Windows NT and have been part and parcel of Windows Servers versions ever since. They also know that it's always been a little trickier than it should be to impose and then to enforce such policies in Windows applications.

Those tempted to simply understand and interpret password complexity rules can find plenty of guidance in all kinds of Windows literature online. Those tempted to do things the Windows way will find the TechNet article Step-by-Step Guide to Enforcing Strong Password Policies of considerable interest -- at least until they learn that following this excellent set of steps requires using and installing Windows Server 2003 as a domain controller, as well as operating Windows XP Professional desktop PCs within that selfsame domain environment.

More on this topic from
Adding 'fudge' to your passwords 

How to create a secure login page using ASP.NET 

Forms Authentication differences in ASP.NET 2.0 

After that comes the steps involved in implementing the advice regarding the presence of an actual password, minimum password length, and the presence of upper- and lower-case alphabetic characters, as well as numbers, punctuation, and perhaps even higher-order ASCII characters (code values from 128 to 255) that may only be entered using control characters sequences at the keyboard.

The obvious way to implement these rules is by embedding code within an application to solicit password input, then pass or fail user submissions on the basis of whether or not the stipulated constraints are met.

But it's far better to create a separate component to handle this task, which may then be used whenever passwords must be supplied or interpreted. Better yet, this modular approach not only facilitates re-use of the same component wherever it's needed, it also lets you keep all password logic in one place. This latter characteristic has value because password policies, like other policies, have a strong tendency to change over time -- and by putting all this logic in one place, you need only make changes to a single component when and as such changes occur.

In Visual Studio Magazine, John Cronan presents compact XML notation that captures common password constraints in simple and elegant fashion. Comments provided are mine, however, not his:

<minAlphaChars value="2" /> 
<!-- Passwords must include at least two alphabetic characters -->
<minLength value="8" />
<!—Passwords must be at least 8 characters long -->
<minNumericChars value="2" />
<!-- Passwords must include at least two numeric characters -->
value="1" chars=
{}|[]\:"<>,./?" />
<!-- Passwords must include at least one punctuation character -->
<!-- Character values shown define the full PuntuationChars set -->

The beauty of XML, of course, is that it can be interpreted programmatically into just about any form, including code in many languages. As policies change, you need only update your XML markup for password rules, then re-load the changed definition into your password component, and the logic changes transparently every place your password handling component is invoked. It just doesn't get any better than that!

About the author: Ed Tittel is a writer and trainer whose interests include XML and development topics, along with IT Certification and information security. E-mail with comments, questions, or suggested topics or tools to review. Cool tools rule!

This was last published in October 2006

Dig Deeper on Software Security Test Best Practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.