Dear Password Pt. 2

Posted on 22 September 2018

Last time I started ranting about passwords and how it might be better if we attach a price to them. I ended off by saying a more complex password will lead to “more expensive passwords”. Today, I go on by talking about password complexity.

Password Complexity

Longer passwords. Stronger passwords. Passwords with a mix of uppercase, lowercase, numbers, and symbols (which will effectively give a search space of 94 characters). These passwords will take longer to crack (and increase their value), but how do we force users to have such intricate passwords? By enforcing password complexity, of course! And it is so easy to do, too.

A couple of clicks in the “Domain Security Policy” in Microsoft Windows Server and a system administrator can enable a plethora of Password Policies. So, what does Microsoft believe to be the underpinning of strong password management? Let us look at Microsoft Windows Server 2012 Password Policy.

First, one can “enforce password history”. The default value for this is 24 passwords. This means that the user must have had 24 unique passwords before an old password can be reused. This sounds legit. The basic rule of anything relating to cryptography is to never reuse the same key (or in this case, password), right?

However, the next policy is that of a “maximum password age”. Default setting: 42 days. A user is now forcibly required to change their password to a unique password (that hasn’t been used for the previous 23 passwords) every 42 days. Effectively, the user will have to stay employed at the company for 2 years, 9 months and 7 days before they are allowed to reuse the same password (given that they change their password no less than every 42 days).

There is a policy that forces a “minimum password age”, but the default for this is 1 day. A user can change their password once a day, if they so desire.

The next policy affecting the user is that of a “minimum password length”. As we saw above, a longer password is worth more than a shorter password. The default minimum password length is 7 characters. Which falls in the range of a “cheap” password. However, Microsoft Technet suggests that the “best practise” for a minimum password is 14 characters. Every 42 days, for almost 3 years, the user must remember a new 14-character password.

But, that is not all. The password should not only be long and short-lived. It should also meet a stringent set of “complexity requirements”. Default? Enabled. And the definition of this complex password?

  • It may not contain the user’s account name or display name.
  • A password must contain characters from three of the following categories:
    • Uppercase characters,
    • Lowercase characters,
    • Numeric characters,
    • Non-alphanumeric characters (special symbols), or
    • Any Unicode character that does not fall into the above.

As of Unicode 9.0 (released in June 2016), there are 128 237 characters to choose from. However, if we only consider characters that are easily accessible on the English computer keyboard, this brings the number down to 94 characters.

If all the above password policies are enabled with their default or “best practise” setting, we can tally it all up to get the following: A user will be forced to select a unique 14-character password from a space of 4 205 231 901 698 742 834 534 301 696 possible combinations, every 42 days for the next 2 years, 9 months and 7 days.

To the systems administrator, this sounds amazing! In the worst-case scenario, (given one hundred trillion guesses per second) it will take 15.67 thousand centuries to guess the password. And considering that the passwords are hashed, even longer! This is turning out to be a very expensive password. Amazing!

Brute force guessing should theoretically not be possible, as the information system should not allow multiple incorrect password attempts. Strangely enough, the default setting on Windows Server 2012 allows for unlimited password attempts before an account is locked. This surely allows the user to try to remember their password out of four octillion possibilities. Not only the user, but the malicious actor can try as well. Luckily the “best practice” suggestion is between 4 and 10 attempts before the account is locked and requires human intervention (in the form a helpdesk call) for it to be unlocked.

There are not very many people on this planet who enjoy memorising strings or sentences for fun. Especially if they are forced to do so every 42 days. So, do all these policies all dwindle down to less security?

More Complexity – Less Security

The first thing a person is taught when remembering something complex is to write it down. Students do it in classrooms for examination tips. Waiting staff do it in restaurants for orders placed. Office workers do it to remember their password. Every 42 days a notebook comes out, or a new sticky note is attached to the screen (or more “securely”, under the keyboard) containing their newest password.

There is nothing intrinsically wrong with writing down a password. To gain access to the password, the malicious actor will need physical access to the sticky note. In fact, a senior programme manager for security policies at Microsoft, Jesper Johansson, suggests that all users write down their passwords – a suggestion endorsed by crypto-expert Bruce Scheiner way back in 2005. Yet, we still have security audit companies telling their clients to discourage writing down passwords.

If the note on which the user’s password is written happens to be pinched, the system administrator can rest assured that at least the password will become invalid within at most 42 days. If a user discovers the disappearance of their sticky note, they can manually change their password as well (assuming it’s after the minimum password age, of course).

To quickly summarise the reasoning behind the complexity and age policies of passwords: they prevent malicious actors from guessing passwords and if a password is revealed, it won’t live long thereafter.

Unfortunately, this is not so true. A team of researchers at the University of North Carolina developed a framework that can search for a user’s new password using their old password. The reason for this is that users do not choose unique passwords from their four-octillion possibilities. Users tend to use common techniques to slightly alter their existing password in order to comply with the password complexity policies.

Another study questioned the security of password expiration in a quantifiable manner. They found that that the benefit of a maximum password age to be miniscule at best.

Is there anything that can be done to help the user in their pursuit of unique, safe passwords, especially when users need to use password authentication for more and more applications?

Write it all down!

The password manager is an application that stores multiple passwords in a “password vault” which is protected by a master password. Once the vault is unlocked by the user’s master password, any system that requires the user to authenticate will have their credentials automatically completed.

Most password managers come with a feature to generate a unique, secure, and random (a really “expensive”) password for each system the user uses. The user is under no obligation to remember this password as it is securely locked up in their vault. The vault can even follow the user between devices. The only requirement for the user is to have a secure master password. At least they do not need to generate and memorise multiple such passwords. However, a user making use of a password manager will probably already know about the security implications and thus have good password management.

This seems like the ultimate answer for secure passwords – as long as the vault (and master password) stay secure. There is a trust in the provider of the password manager. Providers that make use of cloud storage for this password vault need to ensure that their storage is secure. However, some providers use the master password not only as a form of authentication but as the actual key to encrypt and decrypt the password vault. The obvious drawback is that if the user forgets their master password, their password vault is essentially a digital paperweight.

But, assuming the user can remember at least one secure password, unfortunately, some applications have gotten it in their minds that the password manager is… insecure.

Although there is a small vector for an attack against the password manager (like small), some websites have taken it upon themselves to completely denounce and disallow the use of a password manager. When users question them about this, the customer support will simply utter that it is “for security reasons”. What does this do? It forces the user to manually copy (as in type letter for letter) their secure password, or have a simpler (cheaper) password.

Luckily, the simplest means of disabling the password manager (by means of setting an autocomplete=off tag) can be actively ignored by most modern browsers. However, this does not help corporate users who must create multiple secure passwords in environments where corporate restrictions exist for non-company applications (i.e. password managers). This means these users still have to memorise (or manually write down) their passwords.

However, considering the home user, this could potentially save users from having their cheap password guessed and removes the risk (and time-consuming password changing) of a breached password that was used on multiple sites.

What Now?

If it has not been clear yet, in this post we defiantly put our foot down and said “no more” when it comes to passwords. Passwords have been weak since its inception, yet more and more information systems rely on them.

It should be clear that passwords can only be secure if they are unique and expensive, but this comes at a premium that most users do not want to pay. If passwords have effectively been a broken authentication system for half a dozen decades, why do we still use them? There must be something better!

Stay tuned!