Password Auditing

Why Audit?

Harriet Beecher Stowe is credited with the quote “Human nature is above all things lazy” – while I prefer to think of myself as ‘efficient’ rather than lazy I think the principle is sound. When faced with the choice of executing a task in a difficult or simple way (with no difference in the outcome) then people will naturally choose the simple way. This leaves more physical and mental resources available for the truly challenging things in life.

The same is true for most users when selecting a password; the perception to the user is the complexity of the password doesn’t matter, but the process of changing a password is time-consuming or cumbersome. With those two facts the user is going to opt to use a password that they are confident they can remember when needed.

To ‘fight’ human nature and to help ensure our users implement complex passwords we enforce password complexity. This (we believe) ensures that our users will start using passwords that are hard to crack.

But what we forget is the difference between brute forcing passwords and easily guessable passwords. In Flavio’s presentation about the exponential nature of password cracking costs he showed that, from a brute force point of view, each increase in the length of the password and the number of possible characters significantly increased the time it would take to grind through all the possible password combinations.

But that is simply talking about brute forcing; there are two things to remember about bruteforcing:

It is dumb, you are just trying all of the possible combinations until you find a hit
Assuming you know all the characters used and the password length (or the range of lengths that the user could have used) you will eventually discover the password

So, eventually a brute force attack will work; though eventually can be a very long time. Jason Fossen via SANS has a great spreadsheet that shows the calculations of how long it will take a set of 100 computers each cracking 200,000,000 passwords per second (for a combined rate of 20,000,000,000 passwords attempted per second). Assuming the password requirements is for a password to have at least one of each of the following:

Lowercase letter [abcdefghijklmnopqrstuvwxyz]
Uppercase letter [ABCDEFGHIJKLMNOPQRSTUVWXYZ]
Number [0123456789]
Character [!@#$%^&*()_+{}|:"<>?~`-=[]\;’,./]

Giving a pool of 93 possible characters; if we assume the minimum password length is 12 characters then it will take approx 2,422,432 days (~6,636 years) to try every possible combination (though you would have to be a pretty unlucky attacker if the last password combination your great (great, great, great etc) grandchild tried was the one that worked. The average time to crack should be half, which reduces it to 1,211,216 days or ~3,318 years. which clearly means the account or the data is most likely useless/non-existent by the time you crack it. If the password fails to crack quickly most attackers will reallocate their password cracking resources to another password. As a result most security professionals are not concerned about a password being cracked that far in the future.

But brute forcing assumes the users are doing completely random combinations; and my premise is that they will not. As a security professional I am less concerned about a password being brute force-able but I am worried about the password being guessable. By guessable I don’t mean plucking it out of the air but based on a dictionary word with some basic changes.

What kinds of changes? Well, if there is a password length then take a dictionary word and add numbers at the end or beginning to make it the right length. If you need a special character then try one of the characters above the number keys [!@#$%^&*()] as they are the most common and put it at the beginning or end of the word (as those characters require two fingers to press so are easiest to do first or last). Do common letter -> number substitutions (replace a’s with 4′s, e’s with 3′s etc).

Let’s say that our user has a password of password3 (yes, you guessed it, it is the fourth time they have changed their password) – but then a new security admin starts and emails everyone saying that at the next password change a password complexity policy will be enforced. The new rules are the same as the above (The password must contain at least one: lowercase letter, uppercase letter, number, character and be at least 12 characters long). Damn those security people, don’t they know that folks are trying to get shi…work done! So at the next password reset the user has a think and comes up with the following password:

!Password123

This meets all the requirements, has the right characters and is the right length – but for someone doing more intelligent password guessing (vs dumb bruteforcing) this is going to be on their guess list. So the password meets the complexity requirements but is not complex to guess.

The security guy overhears the worker bragging in the cafeteria that he has ‘beaten’ the password requirements, and updates the policy. The passwords can no longer contain a dictionary word… so the next time the user has to change his password he switches it to:

!P4ssOrd123
Again, it meets the password requirements but is still guessable.

How do you Audit?

How do you protect against this? As an administrator what are the steps you can take to ensure the passwords being used by your employees are not easily guessable? Through regular password audits. This process is already taking place within some government organizations; at regular intervals they attempt to ‘guess’ their users passwords using a strong word list and notify those users whose passwords are to easily guessable.

With the release of Impact v2013 R1 we automated this process for our users; in a nutshell the process is as follows:

Extract the hashes for the accounts you want to export using Impact
Pass the hashes to CORE CloudCypher
CloudCypher will tell you if the passwords are crackable or not

If they are, you can notify the users that their passwords are not strong enough and request they change their password. This could be done across all of your user base or in samples (get the hashes for every user who changed their password in the last week, for example).

Alex Horan – Impact Product Manager

Fuente: resources.infosecinstitute.com