AD and enforced password policies

Tue Jan 3 00:21:12 UTC 2012

On 02/01/2012 20:27, Jones, Barry wrote:
> Specifically, I need to enforce the use of length, special characters,
> and be able to validate the enforcement of such.

I always like to look at policies like this from an analytical point of view.

Let's take a look at some numbers.  Let's say that you insist on mixed
case, numbers, punctuation, 8 characters.  I find anything more than 8
characters really difficult to remember; probably lots of other people too,
which is why they all write them down on post-it notes if they're longer -
and then stick them to their monitors.

This creates a pool of 26 + 26 + 10 + 10 = 72 possible characters.  So in
theory you're talking about a pool of 72^8 = 7.2*10^15 possibly passwords.

Thing is, your password policy insists on punctuation, which means that
your actual password pool is now 10*72^7.  i.e. one character is pulled
from the pool of 10 punctuation chars, and the rest are anything at all.
And if you insist on at least one number + one item of punctuation, it's
10*10*72^6 - same reasoning.

But really, you're also insisting that you use at least one upper case +
one lower case letter, which means that your password pool becomes
10(punctuation)*10(number)*26(upper case)*26(lower case)*72^4 = 1.8*10^13.
 In other words, by enforcing a strict password policy on your users,
you've just reduced your potential password pool size by a factor of 400,
which means that your password is 400 times easier to brute-force.

The next step in this process is to take a look around at the current
capabilities of GPU based hash generators.  E.g. whitepixel currently
claims to be able to handle 3.3*10^11 md5 hashes per second (unsalted) on a
computer with a very small capital outlay.  If for some odd reason you were
storing your passwords as unsalted md5 hashes, your entire password set
would be cracked within about 1 minute.

But real life is different; we don't use md5, we do use salt, and we don't
choose stupid password policies.  Oh but wait, we do.

So the real question you need to ask yourself is this: "what is the
intention of my password policy?"  Is it to create a sequence of characters
which is effectively impossible to brute-force?  Or is it to create a
sequence of hieroglyphics which your users will find difficult to remember
and will cause them to grind their teeth in anger every time they are
forced to type it in?  At best, these hieroglyphics provide an elevated
sense of security.  At worst, they are a mockery of actual security.

My favourite choice is "Pa$$w0rd".  It scores top marks on pretty much all
password strength checkers that I've ever tried it on.  And every time the
policy requires a change, I prepend a digit which apparently makes it
secure for another 6 months.

If you are more interested in creating passwords which are difficult to
brute force and easier to remember, one useful approach is to take a list
of a couple of thousand short-ish words, and to use a random list of five
or six of these words for a password.  Much easier for people to remember;
gets around silly mistakes with typos; and there's no requirement for mixed
case, punctuation and all those other silly things which look great on
paper but serve only to confuse and annoy.

Nick