How To Make Sure Your Secure Password Policy Is Actually Secure

Part One – The Password Policy Mine Field.

Password Policies, Where To Begin?

We all know the definition: a password policy is a set of rules designed to enhance computer security by preventing users from configuring weak and predictable passwords and protecting the passwords from common attacks such as automated guessing. Yet how do we actually decide which rules are appropriate for our password policy? There is a great deal of conflicting online advice regarding Password Policies, and so it can be challenging to configure a policy that is both secure and user-friendly.

The general consensus is that a good password is complex enough to withstand guessing, yet not so complex that it becomes difficult to remember. This is no easy task, especially considering that most applications, websites, alarm codes, phone pin numbers etc. follow different policies.

When policy restrictions are in place, it is typical for users to configure the weakest possible password that meets the restrictions. For example, if Microsoft’s Active Directory is configured to enforce ‘password complexity’, then three of five requirements must be met. These requirements include restrictions such as the minimum password length, the inclusion of numbers and symbols etc. However, even with the policy in place, users can configure a password such as ‘Password1’, meeting the three requirements of eight characters in length, an uppercase letter, and a number. It is hardly surprising that ‘Password1’ remains one of the most commonly configured passwords.

Often, a user may attempt to increase the complexity of their password using techniques such as leet speak, swapping out certain letters for numbers, such as P433w0rd1. However, Leet speak is a very well-known form of string manipulation. Other common techniques include appending or prepending symbols, years, months, adding ‘.com’ to make the password a web address, etc. The irony is that these well-known techniques can often make a password significantly easier to guess (or crack).

When it comes to cracking passwords, brute forcing is rarely used, especially not if the attacker wants to crack the password quickly. Password attacks have become more sophisticated, not just in terms of the availability of computing power, but also in terms of how the tools approach the task of tying millions of possible passwords to find the one configured by the victim.

Rather than attempting all possible combinations of letters and numbers, or by systematically working through huge lists of possible passwords, one approach is to take each word in a large wordlist, then apply hundreds (sometimes thousands) of rules. These rules aim to cover the common patterns applied by users to their passwords.

Using password rules such as koreLogicRules a variation of common string pattern is applied to each word in a given word list, this is then tested against the password hash. The word list is often a list of the most common password that have been discovered in previous attacks, such as qwerty, 1234567, iloveyou and chelsea.

For example, the word password would be selected, then attempted with a 1 on the end, then a 2, then 2019, then in reverse, then doubled up, then in all combinations of leet speak, etc. until all variations have been applied and the tool then moves to the next word in the list. Therefore, passwords that appear to be complex, such as Jessie2019! can be cracked in seconds, especially when a few thousand pounds can purchase the necessary hardware to attempt millions of possible passwords and variations per second.

Pentest People regularly performs password audits as part of the Penetration Testing services, and these common password patterns are confirmed time and time again, with the vast majority of passwords beginning with an uppercase letter, ending with a number or symbol, and using the minimum amount of characters the policy requires.

So What Can We Do?

Instead of forcing a strong complex password policy that will make the average user create a password that is difficult to remember and does not hold its integrity, the use of a passphrase is the way forward.

A passphrase is similar to a password, but rather than a string of random characters, they are a string of words. They are often longer than a password, easier to remember, and a LOT harder to crack. For example, if we take the following pass-phrase the-cat-sat-on-the-mat, and told an attacker the structure of our pass-phrase but not the individual words, they would have one sextillion combinations to work through (assuming a modest sized dictionary is used). At a speed of 30 million password per second, it could take thousands of years to crack.

What makes a passphrase even stronger is that a structure does not need to be used, you do not need to dictate to a user how many words and the length of words are to be used. Raspberry cream cheese icing will make a very secure passphrase. In fact; a word does not need to be a word, the user also does not have to use a – instead of a space,  numbers can be used in the phrase I get the number 65 bus to work home. The combinations/possibilities are endless.

With a passphrase there are only two things you need to do to enforce your policy:

1. Set the minimum length of the passphrase to be longer something around 16 characters long.  
2. Educate the user to what a passphrase is. Obviously, this is not part of the policy but a customer needs to know what a passphrase is.

Passphrases are easier to remember, so are less likely to be written down, can withstand offline cracking techniques, and will meet even the most stringent of password policies. So perhaps it’s time to consider passwords a thing of the past, and embrace pass-phrases.

Next time we will look into extra security methods we can add to our applications to make them even more secure.

Find out more about our Web Application Testing Services here.