The Paradox Of Password Rules

Many organisations can expect to see some sort of findings on their audit reports pertaining to their system password rules and settings. Examples of these include the number of lowercase, uppercase, numerical or special characters required in passwords in combination with not being able to reuse passwords which have already been used. It is a widely held belief that the more restrictions and conditions that are placed upon passwords, the more secure your systems is. I believe that this is actually a paradox. In my experience, more complicated password conditions actually lead to a proliferation of simplistic passwords which can be more easily guessed or cracked. This actually reduces the security of your system rather than enhance it. It is also much more likely that users will write down their passwords in an unencrypted document on their PCs or potentially on a notepad or post it note nearby as a way of remembering the complicated passwords.

If you have largely unrestricted password conditions, you open up the possibilities that the passwords can be anything. Although you will always get the common ones such as spouses names, children’s names or swear words, there is also more chance that the password will be something completely random since the user has the freedom to choose anything from the languages available across the globe. For example combining two randomly different words together as a single password would mean that the character length is naturally greater and would take an increasingly greater period of time to crack through brute force. To protect yourself from very common passwords many systems, including SAP, have a prohibited passwords list which can be maintained.

If you start enforcing greater levels of complexity, users naturally have to think harder about the passwords which they choose. Having worked on multiple client sites, I dread the time where the little dialog box is sitting there asking for me to define a new password. Often, I spend more than a few minutes trying to think about what will fit the client password conditions and then what I am likely to remember. Until you meet the criteria specified by the system, you will simply get error messages stating the deficiency in your password strength. Once you have finally met the criteria, you will then understand the minimum standards required by the system and therefore understand the likely structure of a number of users’ passwords within that system. Whilst this might actually appear to make the password itself more complicated, you tend to find that more people follow the same thought process and therefore mean that you can actually guess many more people’s passwords than you would ordinarily have been able to. I have lost count of the amount of times people end up with a swearword with a Capital first letter and an incremental number with a $ sign at the end.

A worked example shows the common thought process for building a compliant password yet not actually making it difficult to work out, starting with my first name:

Whilst the password initially appears very secure with a combination of characters which may not easily be guessed, over time, the password settles into a very simple pattern whereby it remains largely static and simply increments the number with each change. 

Therefore, this password has retained its adherence to the complicated convention & standards set by the system yet remains an inherently weak password in general terms. 

In SAP systems, you have the option of configuring an additional parameter, login/min_password_diff, which requires that the password has a minimum number of differences from the previous one. At Turnkey Consulting, we recommend that this is set to “3” as a minimum but even then, users will find a simplistic pattern to meet those standards with as little thinking time as possible.