Welcome!

Linux Authors: Dana Gardner, Elizabeth White, Gary Kaiser, Noel Wurst, Liz McMillan

Related Topics: Perl, Java, .NET, Linux, Security

Perl: Article

The Development of a Perl-based Password Complexity Filter

A useful foundation for developers and system administrators to improve password policy compliance

If you watch the news regularly, it is easy to notice that in almost any given week some company seems to have experienced an electronic break-in or in some other way experienced a form of computer or network compromise. While computer security professionals can help to mitigate such risks via the proper configuration of firewalls, careful crafting of Access Control Lists, the application of updates, and the judicious application of file permission, among other measures, it's important that one of the most fundamental ways of improving the security of a computer or network resource not be overlooked - that of a really strong password. To this day passwords remain one of the weaker links in the security of electronic resources, and their potential for exploitation needs to be examined more carefully than ever. With the growing trend of cloud computing-based initiatives, many resources that were formerly enclosed within the wall of a business are now available over a network, thereby mitigating the physical security measures the previously helped to limit access to such resources. Given that many of these cloud-based solutions are accessed via user name and password combinations, a strong password is often the primary form of defense against illicit access.

The Makings of a Strong Password
One of the best ways to ensure that users of any application you develop have a strong password is to validate the strength of the password via the usage of a password complexity filter, which ensures that any proposed password meets certain minimum complexity requirements. In order to get a clear grasp of the requirements considered essential for a strong password, let's first consider several password usage cases. First let's consider a case where we have an application that only utilizes case-insensitive alphabet characters in a password that's four characters long. If we were to compute the number of possible passwords that could fit into such a "password space," we would see that passwords created with these rules in mind would allow for

26 * 26 * 26 * 26 = 264 = 456,976 possible passwords

If we instead now allow passwords to be case sensitive and distinguish upper and lowercase characters as being distinct, you can readily see that we have increased the size of the password space since we would now have

52 * 52 * 52 * 52 = 524 = 7,311,616 possible passwords

Now if we also allow our application to include passwords that contain numbers we would end up with 624 (14,776,336) possible passwords, and if we incorporate a set of special characters the number of possible passwords would be even greater. You can clearly see that for each additional character set we add, the number of possible passwords that could be created expands. The greater the size of this password space, the harder it would be for a person with malicious intentions to obtain the password, since any brute force attack would require the attacker to try an increasingly large number of password possibilities before the correct password was obtained. Thus our demonstrations so far have indicated that we greatly enhance the security of our passwords by requiring users to create passwords with a combination of mixed case letters, numbers, and special characters since this yields the maximum possible variability within each allowed character position.

Increasing the variability at each position is not the only way of expanding the size of this password space, however. This space can be expanded to an even greater degree by increasing the number of allowable positions. For example, if we consider our first usage case of the case-insensitive password and simply add a fifth position to the password, we would now have 265 (11,881,376) possible passwords and for each additional position we add, we would have exponentially more password possibilities. This illustrates that length as well as positional variability is crucial to creating a strong password. Typically, password minimums are set in the 8-10 character range, but for highly secure systems it may be desirable to require even longer passwords.

In addition, while each of these aforementioned techniques can work to reduce the potential for brute force attacks, by helping to ensure that finding the correct password within the entire search space would take an inordinate amount of time, you should not overlook the fact that too many passwords do not require brute force approaches to find. The human aspect should never be forgotten about, and keep in mind that remembering random strings of letters, numbers, and special characters may not be the easiest thing in the world for many users. Because of this, many users seek to use dictionary words or names as passwords and this forms the basis for the use of dictionary attacks, in which a long listing of names and words are tried as passwords, with the hopes that one will match. Likewise, dates such as anniversaries or birthdays are not a good choice either, since they can readily be incorporated into a dictionary style attack as well. Dictionary attacks are such an established threat, that dictionary words should never be used as a password or as a part of a password.

When considering establishing password policies, with regards to dictionary words, you should also consider that many users seek to use dictionary words as a basis for their passwords with some minor modifications to incorporate special characters and/or numbers. For example, a user might take a dictionary word like "password" and modify into "pa$sword" to meet a special character requirement or they may modify "security" into "s3curity" to incorporate a number. Many dictionaries used for dictionary attacks now include such minor word variations in their word listings, and as such it may be prudent to disallow the creation of such passwords.

In this article we'll look at the development of a Perl -based password complexity filter that can be readily adapted for compliance with the most standard password policies. As such the script could serve as a useful basis for checking the strength of passwords users wish to use for access to Web applications.

The Password Complexity Filter
Before the coding of the password complexity filter is delved into, a dictionary of words should first be created for use by the password complexity filter script in order to flag any password that's based on a dictionary word as being a poor choice. In order to do this, we will make use of a modified form of the "words.txt" file that comes standard with most Linux distributions, but with a minor modification. The words.txt file will be modified to eliminate all words of less than three characters, because the presence of small words in the dictionary such as "I," "a," "at," etc., can lead to many false positive identifications of passwords as being poor password choices because they are based on dictionary words. One other important consideration to keep in mind when running this script is that code itself is portable between both Linux and Windows, but in order for the code to function properly, the list of dictionary words needs to be saved in the text formatting that is used by the platform the code is being run on due to differences in encoding line endings.

Now that the dictionary is established, we can begin to look at the Perl code, which begins by first declaring the Perl modules that it makes use of and opens the file that stores the dictionary list as follows:

use strict;
use Fcntl qw(:seek);
#words.txt file is derived from the linux ditionary file with all words of 3 characters
#or less removed, since small words like "at" and "I" can trigger false positives
open(WORDS, "words2.txt") or die("Cannot open words.txt \n");

The "use strict" pragma is used to help ensure the quality of the Perl code by forcing all variables to be explicitly declared, and the Fcntrl module will be utilized to navigate around the dictionary list file. The dictionary file is assumed to be in the same directory as the Perl script by this code and is opened with the file handle WORDS.

Next the script declares its variables as follows:

my $word;
my $passwd;
my $dc=1;
my $count=0;
my $len=8; #sets the minimum password length
my $minnum=1; #sets the minimum number of digits
my $minup=1; #sets the minimum number of uppercase letters
my $minlow=1; #sets the minimum number of lowercase letters
my $minspec=1; #sets the minimim number of special characters
my @FuzzyStrings;
my $regexp;
my $char;
my $stringpos;
my $i;
my $j;

The functions of each variable will be discussed as they are utilized, but the main variables of interest to those who seek to customize the password complexity filter to suit their respective password policies are the variables that each begin with "$min" since these are used to set the minimum lengths of each password and the minimum amounts of each character type as indicated in the code comments.

The script then seeks to compare the provided password to a list of dictionary words to make sure that none of the passwords contain dictionary words by using the following segment of code:

$passwd=join(" ", @ARGV);

while($word=<WORDS>){
chomp($word);
if($passwd=~/$word/i){
print "Password Contains A Dictionary Word: FAIL \n";
$dc=0;
last;
}
}
if($dc==1){print "Dictionary Check: PASS \n";}

Note that in the variable list above, the variable $dc was set equal to 1, since this variable will serve as our indicator of whether or not the user-provided password contains a dictionary word. The above segment of code loops through each word in the dictionary file and uses case-insensitive regular expression-based pattern matching to determine if the password contains a dictionary word. If the password ($passwd) matches any of the words in the dictionary, the variable $dc is set to 0 and a failure warning printed to STDOUT. If $dc remains equal to 1, a pass message is displayed.

The next check is a straightforward password length check, wherein the length of the password is compared to the minimum required password length ($len), as demonstrated below:

if(length($passwd)<$len){
print "Password Is Too Short: FAIL \n";
}
else{print "Length Check: PASS \n";}

Following this, the script will check to ensure the password contains at least the minimum number of upper and lower case characters, numbers, and special characters by using the following code segments:

while($passwd=~/\d/g){
$count=$count+1;
}
if($count<$minnum){
print "Password Does Not Contain $minnum Number(s): FAIL  \n";
}
else{print "Contains Number Check: PASS \n";}

$count=0;

while($passwd=~/[a-z]/g){
$count=$count+1;
}
if($count<$minlow){
print "Password Does Not Contain $minlow Lowercase Letter(s): FAIL \n";
}
else{print "Contains Lowercase Letter Check: PASS \n";}

$count=0;

while($passwd=~/[A-Z]/g){
$count=$count+1;
}
if($count<$minup){
print "Password Does Not Contain $minup Uppercase Letter(s): FAIL \n";
}
else{print "Contains Uppercase Letter Check: PASS \n";}

$count=0;

while($passwd=~/!|"|#|\$|%|&|'|\(|\)|\*|\+|,|-|\.|\/|:|;|<|=|>|\?|@|\[|\\|]|\^|_|`|\{|\||}|~/g){
$count=$count+1;
}
if($count<$minspec){
print "Password Does Not Contain $minspec Special Character(s): FAIL \n";
}
else{print "Contains Special Character Check: PASS \n";}

In each case, the script counts the number of times the character type of interest appears by making use of global pattern matching (/g), and comparing this count to the specified minimums. One thing to keep in mind is that not all software platforms support the full range of special characters listed here, so that particular regular expression may require some editing. If that's the case, be sure to pay attention to which special characters are metacharacters and keep them prefixed with a backslash to ensure proper compilation and functionality. A sample output using the checks discussed so far can be seen in Figure 1.

Figure 1: "password123" tested against the complexity filter. It is properly detected as a dictionary word and its character composition is correctly assessed.

At this point we have one remaining check to complete and that is the check to see if the entered password is just a minor modification of a dictionary word, which is carried out as shown below:

if($dc==1){
seek(WORDS, 0, SEEK_SET);
my $length=length($passwd);

for($i=0;$i<=$length-1;$i++){
pos($passwd)=0;
while($passwd=~/(\w)/gc){
$char=$1;
$stringpos=pos($passwd)-1;
if($stringpos==$i){
$FuzzyStrings[$i]=$FuzzyStrings[$i] . '.';
}
else{
$FuzzyStrings[$i]=$FuzzyStrings[$i] . $char;
}
}
if($i==0){
$regexp=$FuzzyStrings[$i];
}
else{
$regexp=$regexp . '|' . $FuzzyStrings[$i];
}
}
while($word=<WORDS>){
chomp($word);
if($word=~/$regexp/i){
print "Password Contains A Dictionary Word with Minor Substitution: FAIL \n";
$dc=0;
last;
}
}
if($dc==1){print "Dictionary Word with Minor Substitution Check: PASS \n";}
}

This check will only run if the earlier dictionary check did not find the password to be an exact dictionary word ($dc==1). It initially sets the dictionary word file back to its starting point and computes the length of the password. A nested set of loops and conditional statements is then used to create an array of @FuzzyStrings in which each character within the password is individually sequentially replaced with the "." character. "." is a special character within Perl regular expressions that can be used to match any other character. The result of this nested control structure yields a regular expression that is stored in the $regexp variable, such that a password "abc" would be turned into the regular expression ".bc|a.c|ab.". This means that a password that consists of a substitution of a dictionary word at any single position, to any type of character, will match the created regular expression. Once this regular expression is created, it's then matched against every word in the dictionary list to determine if the password is just a minor variant of any dictionary word (see Figure2). The fuzziness of the regular expression can also be readily enhanced by using quantifiers in conjunction with the ".", as the presence of quantifiers would allow for more than single character substitutions to be discovered. In particular the presence of a quantifier may be desirable for when the first and last character positions are ".", since this will allow for the detection of a partial word being appended to some additional characters.

Figure 2: Demonstration of how the password complexity filter picks up "pas$word" as being a dictionary word with a minor substitution.

Conclusion
This above script illustrates various techniques that can be used to create password complexity filters for use in verifying that existing passwords comply with an organization's password complexity requirements (see Figure 3). Moreover, this script can be run in its current command-line form or readily modified into a CGI application to provide a Web-based interface for making use of the programs functionality. As such, the article and example script should provide a useful foundation for developers and system administrators to improve password policy compliance within their organization.

Figure 3: A password that passes all checks.

More Stories By Christopher Frenz

Christopher Frenz is the author of "Visual Basic and Visual Basic .NET for Scientists and Engineers" (Apress) and "Pro Perl Parsing" (Apress). He is a faculty member in the Department of Computer Engineering at the New York City College of Technology (CUNY), where he performs computational biology and machine learning research.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.