Popular Myths on Password Authentication

by Stephen Thomas  (stephenthomas@rampantsolutions.com)

Security "experts" will typically recommend non-sensible and arcane password schemes in which the user is expected to use a "strong" password incorporating lowercase, uppercase, numbers, and special characters into a seven plus character phrase.

Said "experts" will tell you that should a system attacker gain access to your Windows NT SAM hive or /etc/passwd (/etc/shadow for those of you paying attention), then it is only a matter of time before he will crack all of your passwords, with the weaker combinations falling victim first.

Experience tells us that if an attacker has access to these password archives, then your security problems are much more serious than users having passwords such as alice or spot.

Further, given current gigahertz computing and ever-increasing performance in mainstream computers, one could argue that passwords of any length are insecure and would eventually become trivial to determine.

So given that our password archives are secured and we are not distributing copies of our SAM hive around on floppy disks, where does the threat exist with password authentication?

It is an elementary exercise in scripting to attempt multiple logins given an account name using several potential passwords.  The common response to this brute-force approach is to disable the account after n bad login attempts.  This is not an entirely bad approach.  Assuming n is not too small, it does act as somewhat of an intrusion detection mechanism.  The caveat here is that it is still a trivial exercise to attempt to login n times using a null password with the intent of locking users out of their own accounts.

The threat of such malicious activity within your own organization may or may not be trivial.  Ideally, n is set high enough that system administrators are alerted before anyone is locked out of their account but low enough such that a brute-force attack does not actually succeed.

This is where we rely on probability.  Assume we are going to enforce a password length of at least y characters, and all of our users are not inclined to use any more.  Further assume we are using a set of x possible characters to create the actual password.

The solution set of all possible passwords is thus x^y.  If we require only lowercase letters and a minimum password length of seven characters, then the solution set is 26⁷ or 8,031,810,176 possible passwords.

However, the two largest dictionaries each include around half a million words, of which a liberal estimate of 1/10 are equal to seven letters.  So an educated attacker might reduce the aforementioned solution set to 50,000 words.

Given a solution set of z possibilities, the statistics are favorable that you will find a match given z/2 opportunities.  If we want to ensure that the probability of someone guessing a solution from the set of z possibilities is very low (less than 0.1%), we must ensure that the number of guesses (analogous to our variable n) is less than z/1000.

Assuming we are susceptible to a "dictionary" attack and we enforce a seven character lowercase letter password, we can allow 49 logins before we disable an account and still have a high level of assurance (99.9%) that our accounts have not been compromised.

Varying the length of the password beyond seven characters and including uppercase letters, numbers, and special characters only obfuscate the password to the user and provide a negligible statistical increase in defense against a realistic brute-force attack.  In fact, such passwords can detract from system security as they are more inclined to be written down and thus susceptible to circulation.

There are two situations that may require an enhancement to the above schema.  The first is that given an all lowercase letter password, one may be inclined to use a spouse's name or some other phrase known by a peer, potentially reducing the solution set to as little as ten possibilities.

Again, the threat of such malicious activity within your own organization may or may not be trivial.  A solution here is to incorporate a single number or special character into the password, thus rendering the "selective password" attack unfeasible.  Adding a number into the previous schema increases the potential solution set to (26 + 10)⁷ or 78,364,164,096.  An augmentation of the dictionary attack may try combinations in which a password substitutes a zero for the letter 0, or appends the number 1, but this certainly does not reduce the solution set to less that 50,000, our established worst-case z.

The second situation concerns password sharing, either intentional or inadvertent.  The only way to restore accountability once a password has been revealed is to issue a new password only to the original user.

This requires password changes at some interval (i), commensurate with the frequency of this practice within your organization.

Similar to n, if is set too small, there is greater potential for users to write passwords down, arguably a higher concern than someone actively cracking a password archive.  Security "experts" recommend 30-60 days, but these are the same people who think users can remember passwords like: IlXiot25ey!

They will tell you password phrases can be representative, such as: I like Xmas it's on the 25th each year !

It is ignorant to subject users to this hollow logic.  Consider that most users cannot figure out how to make the paper clip go away in their word processor.

Realistically, enforcing password changes somewhere between once per fiscal year and once per fiscal quarter is appropriate.  Forbidding a password used within the previous couple of terms prevents a user from cycling through passwords to get back to one of which he may be rather fond.

But again it is an exercise in scripting to arbitrarily change the password enough times to bypass this restriction before adjusting it back to our favorite password.  Of course, the counter-defense is to enable a minimum password age.  This requires that, once changed, a password must age for a number of days before it may be changed again.

However, keep in mind that if you frustrate your users, they will write down their passwords and stick them up in their cubes next to the pictures of their kids who are imprisoned in daycare.

Security "experts" will concoct several scenarios: "What if the password archive is compromised remotely by some newly discovered and unforeseen exploit?"  Well, what if someone tunnels a packet through your firewall and smashes the TCP/IP stack inducing a buffer overflow that pops up a remote terminal on his screen in Budapest?  You have to look at security realistically, or it will bankrupt your organization and drive off all of your key personnel who must respond to the aggravating events triggered by inane policy.

Why do we see such widespread fear, uncertainty and doubt concerning password authentication?  Largely because major software vendors want to give you the impression that they are serious about security but they lack true talent and hide the inadequacies of their product by taunting such "features" as "strong password enforcement" because they are trivial to implement.

The true security experts are off designing security and encryption architectures and the popular advice comes from amateurs with laptops and off-the-shelf scanner tools.

So what is a reasonable password schema to enforce?  Ignore mainstream security references that regurgitate the same ridiculous combinations and remember that irate users are more likely to introduce vulnerabilities.

Use your head and consider the statistics, the sensitivity of the resources which you are trying to protect, and your user base.

No specific password schema is appropriate for every organization, even if it sounds really secure the first time you read it.