Problem solve Get help with specific problems with your technologies, process and projects.

Best Practice: Enforcing password complexity

Rather than embed code in an app to address password complexity, Ed Tittel suggests that developers create a component that's used whenever and wherever passwords are needed. This also keeps all password logic in one place.

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.

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.

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 

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!

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!

Dig Deeper on .NET Framework security best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.