Software Design & Engineering
Internet business development
mobile applications
Alan Partis
320 Ridgecreek Drive
Lexington, SC    29072
(803) 692-1101


Password Rules are Stupid
Common rules actually weaken security.

Best Practice ... Not!
This is one reason why "old" code can be touchy.

Wow! That was fast!
Making the right choices in your code can have huge payoffs in speed.

Ctors in Chains
Shrink your C++ code even more by chaining your constructors together.

Virtual Classes
Virtual base classes: what are they good for?!

Practice Makes Pretty Good
Become a master software engineer by practicing like a ninja warrior.

You Should Get Out More
Maintainability is the key to software success.

Why You Need Me
Seven reasons why I think you need me to work for you.

I Create Wealth
Or, why this is such a great business to be in.

Standards in Software
Software engineering standards are a necessary and good thing.

What is a Content Management System?
$10.5 billion will be spent on them this year (2003) alone, but what are they?

Top 10 Benefits of a Content Management System
So what good are they?

Do You Need a Blowfish?
What is a Blowfish? Does size matter? Is it right for me? Get your questions answered here.

Why Not Windows?
Don't just take my word for it ...

10 Attributes of a Professional Software Engineer
A truly professional software engineer stands out from the crowd. Here's what makes them different.

How to Score a Startup
Examine all these points of startup companies and see how they add up.

Password Rules are Stupid

September, 2015

Computer system users are often required to have passwords in a bid to help provide security for those systems and the integrity of the accessible data.  The reasons why such safeguards are put in place are easily understood, but too often, not enough thought goes into the real objectives of passwords, or whether the rules regarding passwords are as effective as they could be toward those ends.

Initially, passwords were employed to keep unauthorized personnel from sitting down at a terminal and gaining access using someone else's credentials.  Over time, it's also become clear there is the additional need to keep remote users (hackers) and their automated systems from gaining improper access.  To be certain, there are two fronts in this battle: the bad actor (we'll call him Bad Brad) attempting to gain access to a system while physically present at an otherwise authorized user's terminal/computer, and the remote hacker (we'll call him Igor) breaking in through another access point.

To keep Brad at bay, controlled-access security systems, locked doors, and other physical security measures are put in place.  Should Brad breach these obstacles, Bob and Alice (the authorized users) are required to use a password to authenticate their accesses to the system.  To that end, Bob and Alice should choose a password that is easy for them to recall, but difficult for Brad to guess.

When trying to gain access, Brad has to bypass physical security (pehraps even get himself invited into a secured building under the guise of corporate training, etc.), then sit down at Bob or Alice's desk and try to log in.  Guessing the username for Bob or Alice is pretty easy as many organizations have pretty standard username rules in place that are based on employee names.  Guessing passwords is harder, and after trying the usual easy guesses, Brad will start looking around the desk for a small piece of paper on which Bob or Alice may have written their password.

Two defenses are already apparent for Bob and Alice: don't use "password" as your password and whatever they do, don't write it down on a piece of paper.

Let's now consider Igor the hacker.  Igor doesn't have to gain access to a building -- he's working from his basement in Eastern Hackistan.  He's got all night and he's got prodigious amounts of computing power at his disposal.  He too will have an easy time coming up with a valid username.  As for the password, he's not likely to even give it any thought at all, he's going to put all his CPU cycles to work on the task of cracking Bob's password.

Igor's programs are going to work through a number of methods, possibly in greater orders of difficulty:

  1. try the foolishly easy passwords (WAY too many people REALLY do use "password" for their password).
  2. dictionary attack, part 1: try a list of the most common words in Alice's language
  3. dictionary attach, part 2: go through Alice's entire lexicon.
  4. brute force: try every possible combination of allowed characters and symbols

All too often, Igor will be successful at step 1.  Even steps 2 and 3 pose very little challenge to him.  But Igor fears step 4: it could easily take more than a lifetime to work through the brute force attack.

In other words, Bob and Alice can defeat Brad by keeping some doors locked and choosing a password they don't have to write down.  And they can defeat Igor by pushing him a long way into step 4.  Frankly, it's easy to defeat both Brad and Igor ... and almost as easy to screw it up and lose the battle.

The point I'm making is that the common password rules actually make things easier for both Brad and Igor at Bob's and Alice's expense.  These rules have become well known to all of us: choose between 8 and 24 characters, use both upper and lower case letters, at least one number, and oftentimes a non-alphanumeric symbol.

An illustration: thinking only about Igor's brute force attack, how many tries would it take for him to guess Bob's password if it is only one character long? That one character could be any of the following:

lower case letters a-z: 26 choices upper case letters A-Z: 26 choices numerals 0-9: 10 choices symbols .?!@#$%^&*()-_=+: 17 choices

Igor will be able to guess Bob's password in, at most, 79 tries.

What if Alice's password is 2 characters long? 79 x 79 = 6,241 tries. That is still a trivial challenge to Igor's massive computer power.

Bob could choose an 8-character password and push up the math for Igor:

79 x 79 x 79 x 79 x 79 x 79 x 79 x 79 = 1.5 quadrillion

Now we're getting somewhere, 79 to the 8th power is a LOT of work for Igor! Clearly, longer is better.  Just imagine how impossible it would be if Alice was smart to use a password that was 24 characters long!

Let's consider what happens when we implement the all-too-common 'stupid' password rules: one of those 8 characters must be chosen from the much smaller set of upper case letters, and another from the lower case.  Another from the even smaller set of symbols ... and yet another from just 10 numerals.  Now, for Bob's 8-character password, the math looks like this:

26 x 26 x 17 x 10 x 79 x 79 x 79 x 79 = 4.4 trillion

Igor's brute force task has gotten exponentially easier.  In order to meet the ojectives of the crazy rules, Bob might choose something like "Bob-1217" using his name and birthday as his password -- easy for him to remember without needing to write it down.  However, that will not present much of a challenge to either Brad or Igor.  Alice, instead, might choose something like "Yu73.qtu" to make things tougher for Igor, but she is much more likely to write it down because it is more difficult to remember, and thereby made things quite simple for Brad!

This is a natural tendancy for Bob and Alice: the more complex the password rules, the more likely they are to write things down (helping Bad Brad).

Consider, instead, an easier set of password rules: use only lower case letters but have a minimum length of 12 charcters.  Grab a calculator and do this math: 26 to the 12th power equals 95 quadrillion! Igor's job just got over 60 times harder and things got easier for Bob and Alice. 

The obvious solution is to simply require longer passwords and remove the crazy restrictions.  By definition, "restrictions" restrict the 'universe' of possible passwords for Igor to work through in his brute force attack, but they also tend to cause Bob and Alice to assist Brad by writing things down that are difficult to remember.  That's a win-win for the bad guys and a lose-lose for Bob and Alice.

Here are the things for Bob and Alice to do to win every time:

  1. think of a "pass-phrase" rather than a password (composed of multiple words, preferrably unrelated and that don't appear in common prose)
  2. use a minimum length of 16 characters

After that, anything goes.  Bob might very well choose something composed of all lower case letters such as "bluecatbasketball" or Alice could go with "Yoga.makesMe19snowball" and in both cases Brad and Igor are much more likely to be out of luck.

The key to password strength is size, not complexity.

I've been making this argument for several years and oftentimes it feels like I'm rowing a small dinghy against the current in the ocean, but it turns out that I'm not alone.  Some smart British folks have recently seen the light:

UK Government Communications Headquarters: Password Guidance.

UK National Technical Authority for Information Assurance: Making Security Better: Passwords.

Welcome aboard!

"Thundernet" is a trademark of Thundernet Development Group, Inc.
a Florida corporation.
Copyright © Thundernet Development Group, Inc..
All rights reserved.