Password Policy

More Restriction Does Not Necessarily Mean More Security

Today I would like to address a problem which has been occurring more frequently in connection with the security of various systems: access passwords. To those of you who have not read my first series dedicated to data and system security, let me remind you that any system security evaluation always encompasses both the technical and organizational security measures where the organizational component (today usually referred to as policy) is at least as significant as its technical support.

As a positive development of the last (approximately) 10 years, managers no longer view the technical support of numerous policies and sets of rules required to access various files and functions as the programmers’ unnecessary efforts to increase the contract volume, which was often the case toward the end of the last century. Consequently, all major operating systems provide support to highly complex structured policies. However, as is the case with every technical progress, this positive fact has its downside: many administrators strive at all costs to apply as many options provided by the systems as possible, often without due consideration whether they are necessary or whether they are not even contra productive in their given use.

The most common consequence I often encounter as a user in the public internet environment is the number of various restrictions related to the permissible user password form. I will leave aside completely, and quite intentionally, the question whether the “classic” sign in with the username/password pair is worthy of the 21st century, and refer those interested in a deeper reflection on this topic to the first series of these articles, especially the chapter dedicated to the NOTEZA platform. Instead, I will focus on what the form restriction pros and cons are, when their use is appropriate and when they are rather contra productive.

In my experience, I have come across three types of restrictions, sometimes in a mutual combination:

1) A required number of various font types (lowercase and capital letters, numerals, other characters) in the password.

2) A required password change after a certain period of time.

3) Impossibility to set up a password which has been previously used and later changed.

At first glance, it seems that the rationale behind each request above is obvious and its implementation should always improve the overall security. Let’s take a look at the contraindication of their use.

According to the general rule, a user should:

  1. a) use a different password for each server (and preferably for each service on the server),
  2. b) not use an easily guessed combinations (name, service title, date of birth…), and
  3. c) definitely not write down the passwords anywhere (and then lose the slips of paper or leave the note files accessible on his computer).

However, most users are not genius children with an infallible memory. Therefore the easiest way to comply with the rules above is to use a specific system for creating difficult to guess passwords, different one for each individual service. Then it is sufficient to master this (often relatively simple) system and use various service parameters (I am not deliberately more specific, so as not provide an excessive guidance for any attack attempts) as a mnemonic aid to retrieve (re-generate the same) password.

A problem occurs when the generated password does not meet the requirements for concrete numbers of various type characters. A user may then easily resort to some of the following, inadvisable practices:

  1. a) generates a sufficiently long, random password containing every conceivable character type and then uses it on all his accounts – and therefore, by breaching one password, an attacker gains an access to all his accounts,
  2. b) writes down the password with all the consequences related to the note being lost or stolen or
  3. c) starts using easy to remember (but easy to guess as well) elements – date of birth for the numerals, names for the capital (first) letters …

No matter how obvious it is that users should not be permitted to use passwords such as “123”, “password” or the server name, the mathematical truth is that (even when using 7-bit ascii) 128n (a number of n combinations of arbitrary characters) is always greater than 10k * 26l *128m (k of required numerals, l of required capital letters, jjom of remaining (arbitrary) characters), even when k+l+m = n. As a result, there is always a good reason to consider whether and to what extent we should restrict the used password format and how much we should redirect our focus toward users’ education and remind them of their responsibility (e.g. an obligatory consent that the provider is liable for any breached password that was evidently weak).

Another problem may occur if the user is not able to use his own system that allows him to remember a “pseudo-random” password easily. With servers operating on such a basis, users (especially those who visit the server in question only sporadically) often prefer to follow a procedure that allows them to recover or change their password every time.

At the same time, one must recognize that these procedures are often implemented by sending an email, and even in case when the provider himself sends the email via a secure (encrypted) access to the SMTP server whose operator he trusts, he has no control, much less a guarantee, that the mail will continue to be transferred securely or which servers will be used to transfer it. And even if all is secure in that respect, the user himself often accesses his mailbox on an unsecured website…

Additionally, in my experience these days, I still come too often across “reminder” emails that contain the actual password in the form of plain text instead of including a link to change it. Security of such a solution surely does not require any further comment …


No matter how tempting the password format restriction is and how “more secure” it sounds and how much safer it seems to force the user to select preferably a different password every day, in a combination with the user’s convenience, memory capabilities, and the necessity to recover a forgotten password more frequently, it often results in “modus operandi” which, in its consequences, may even become significantly less secure than leaving the password form and changes within the user’s responsibility, optionally supported by suitable, educational recommendations.

Another option lies in an individual work with users based on the password strength random inspections in the posteriori security strategy which I will describe in more detail in one of the future chapters of these new series.

An interesting fact:

As in the previous series, I will always try to end each chapter with some interesting news or fact. In this case, I will quote a recent NSA study and its openly published (naturally, without any further details) overall results. According to this study (or rather actual breach attempts), more than 70% of the U.S. critical infrastructure active elements can be accessed from the public internet without a password or with default passwords published in the respective device manuals. There is no need to comment on the significance of these findings, I’m afraid.