The Myth of Complex Passwords

Where did it all start? The time before the Windows complex password policy!

Before the ubiquitous Windows complex password policy was a standard, corporations allowed their users to arbitrarily manage their own passwords. While there were a few exceptions, the important item about password complexity during this time was the lack of security.

Passwords like “password” or “incorrect” used to be acceptable and allowed.

It wasn’t until the release of Windows Server 2008, that a new feature called “Fine-Grained Password Policy” was released and available to corporations. And even after the release of this feature, it still took years for major companies to adapt to this new rule, mostly because the focus on cybersecurity wasn’t high.

The Good, The Bad, and The Ugly of Complex Password Policy
Before we can talk about why it doesn’t work, let’s talk about what it is. Password policy is a set of rules built into systems (ex: windows domain controller) that govern over what is considered to be an expectable password.

Policies are generally based on:

• Password History
• Password Length
• Password Complexity
  • password may not contain the user’s same account name or display name
  • password must contain characters from 3 of the following categories:
    • upper case
    • lower case
    • number
    • special character
    • unicode character

Microsoft Official Documentation on Countermeasure for weak passwords.

Configure the Passwords must meet complexity requirements policy setting to Enabled and advise users to use a variety of characters in their passwords. When combined with a Minimum password length of 8, this policy setting ensures that the number of different possibilities for a single password is so great that it is difficult (but not impossible) for a brute force attack to succeed. (If the Minimum password length policy setting is increased, the average amount of time necessary for a successful attack also increases.)

The rules above may look like a means to protect and secure a user account and help to ensure strong passwords are being used. However, this system of “complexity” can be easily bypassed by a user and allows generally weak passwords to still exist.

Let’s take a deeper look and use the following as our password policy.

Password Length: 16 characters

Password Complexity: Enabled

The following passwords based on these rules above will all be considered the same strength and pass as complex passwords:

• Z79uywm2xNS!?#!s
• WeakPassword2020
• WeakPassword20..

As you can clearly see from the example above, not only are two of the three passwords not really complex, but the password policy allowed them.

Some may argue that the weak password above is not a flaw in the complex password policy but rather a user error, and that argument is correct. This issue is a both a user and company flaw in the roll out of complex password policy.

So why is it such a struggle for a user to create a truly complex password that is secure?

The default Windows complex password policy in hindsight looks like a good idea that should keep the user safe, but instead forces most users to use simple passwords that can be easily remembered and that have to be changed every `n` months, and can’t be reused for `x` months.

In those scenarios, users tend to create a pattern for passwords that will allow them to easily remember and reuse the passwords.

Here is an example of a user schema that allows them to easily remember the password and only have to append/modify the password slightly to be within compliance.

Example:

• IHatePa$$wordPolicy01 => IHatePa$$wordPolicy02
• IHatePa55wordPolicy. => IHatePa55wordPolicy..

Generally users tend to fall into one of these buckets when creating passwords:

• Use PII Data
• Use random 3-4 dictionary/slang words
• Keyboard walks
• Use their surroundings
• Reuse passwords
• Use strong password with good password posture (very few)

And to help meet password complexity they will use one or more of the following:

• Leetspeak (character replacement ex: e → 3)
• Append numbers to the begin and/or end
• Append special characters to the begin and/or end

Below are some real life examples taken from real users (the passwords have been altered slightly to help protect the identity of these weak passwords):

• zaq1@WSXcde3$RFV
• R3dHamm3rPigs…
• SummerOf1969!!!!

At first glance only one or two of these passwords are possibly insecure, but all are easily cracked in less than one minute.

Let’s break them down and talk about each password.

1. zaq1@WSXcde3$RFV

This password creation is referred to as a Keyboard Walk meaning that the user is just using the placement of keys on the keyboard, followed by a pattern to help create a “secure” password. As you can imagine, this and other keyboard walks have been incorporated in almost every word list that is used by attackers.

2. R3dHamm3rPigs…

This password creation is referred to as a dictionary with leetspeak and appended special characters. This means that the user chose three random words and then did a leetspeak of “e” → “3” and appended 3 “.” to meet password complexity.

3. SummerOf1969!!!!

This password may seem like the password above, but in reality is actually the user’s favorite song (which they mention on their facebook account, with public view turned on), with special characters appended at the end.

Another issue is Integrating PII data Into the Password

Personal Identifiable Information (PII) is defined as:

Any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means. Further, PII is defined as information: (i) that directly identifies an individual (e.g., name, address, social security number or other identifying number or code, telephone number, email address, etc.) or (ii) by which an agency intends to identify specific individuals in conjunction with other data elements, i.e., indirect identification. (These data elements may include a combination of gender, race, birth date, geographic indicator, and other descriptors). Additionally, information permitting the physical or online contacting of a specific individual is the same as personally identifiable information. This information can be maintained in either paper, electronic or other media.

By using social media and other open source intelligence (OSINT) sources, someone can access data that a user might use for password creation and might allow them to guess a user password.

Some examples of PII data used to guess passwords are below but not limited to:

• Words
  • Kids Names
  • Spouse Name
  • Pets Name
  • Nicknames
  • Company Name
• Numbers
  • Date of Birth (DOB)
  • Anniversary Date
  • Kids DOB
  • Lucky number
  • Age
  • Kids Age

The exhaustive PII list could be a separate blog post, but having password guessing information by itself is not useful.

Even if someone was able to only get 10% of all the PII data for a user then run it through all the different combinations, plus add special characters and leetspeak, it would take a long time to figure out the user’s passwords.

By using a tool called Common User Passwords Profiler (CUPPS), someone can generate all this data into a nice compile wordlist that can then be used against the user in less than five minutes.

With the aid of software, an attacker can bruteforce all the possible combinations against a user in less than a minute based on a machine running 2 Nvidia Titan V cards, using Hashcat with password cracking experience.

Password Reuse and Breach Data

Another method of guessing a user password is by using leaked data (aka breach data). By searching for that user’s known email addresses an attacker can then try to use those known passwords to see if that user is reusing passwords across systems.

Password reuse is one of the biggest threats in password management. This type of attack not only checks to see if an attacker can access the target account, but also checks to see if they can indirectly access the target account.

For example, a work email account may be secure with a strong password. However, if a recovery email for that account is another email account that is using an exposed leaked password, then someone can trigger a forgot password process and use that exposed account to capture the reset password link and then change it to something that they know.

This is why password management is not just limited to only a few accounts, but to the user as a whole.

A new hope, the light at the end of the tunnel

So there’s a hope, but this hope is not one that comes without a change in mindset. This will require educating users on the importance of passwords and helping them understand that this shift needs to be embraced across the board. Password reuse can have harsh consequences and should be avoided at all costs.

Individual users should take the needed steps to minimize their PII data, by making their social media accounts private/restricted.

Companies should look into using password management software that will aid users on creating and managing passwords for both professional and private accounts.

An example of such management includes the open source project Password Pwncheck project.

This project provides a password testing web server that can be hosted on-premise, and lets users test passwords via a website, along with modules to validate passwords are historically unique, do not exist in breached databases, and meet any other criteria that may be established in company policy, like length.

It has an interesting tokenized password feature that allows passwords to also be tested for similarity to previous passwords or breached entries. Administrators install modules for Windows Active Directory, MIT Kerberos (Linux/UNIX), and/or PAM to enforce these policies across an enterprise, along with a rest API for expansion.