Ah.... NOW I see what you mean... As in, if you required all 4
complexity requirements, and you knew the first three characters were
Aa1, then you'd know for a fact that the last character had to be a
"special" character...
Only problem with that is that a BF attack does not give us one
character at a time. You have to "crack" the hash in singularity...
meaning that your BF attempt would not be able to discern that the first
3 were Aa1 in order to only try special characters for the 4th. Nor do
you know how long the password is, so you'd have to try all possible
characters for each column. Which means, the more keyspace == more
combinations again. This is particularly true when you consider that
requiring ALL complexity requirements does not preempt one from using
more than one as in Aa11aA$$$%%%Aa11. So, even knowing the complexity
rules are in place don't really help you.
Interesting thread, though.
t
-----Original Message-----
From: listbounce@securityfocus.com
[mailto:listbounce@securityfocus.com] On Behalf Of Ansgar -59cobalt-
Wiechers
Sent: Thursday, August 16, 2007 11:08 AM
To: focus-ms@securityfocus.com
Subject: Re: Password complexity - improvement
Bruce,
On 2007-08-16 Bruce K. Marshall wrote:
Requiring users to create a password of uppercase, lowercase,
numbers,
and symbols encourages stronger passwords, not weaker ones. The
loss
of possible password choices is negligible and has no negative
impacts
other than on the usability of the passwords themselves. I'll be
happy to share the math backing this up if you really want to argue
the point.
I do not agree that the loss of possible passwords is necessarily
negligible. I'd like to see the math to back up this assumption. And
in
any case the decrease of the total amount of possible passwords does
by
definition mean you have a negative impact on security. The impact may
indeed be negligible, but you still need to be aware of the fact to
make
the distinction.
Besides, even complexity requirements can't replace user education. A
password like "b@n4Na" would be compliant to the policy in question
and
still susceptible to dictionary attacks.
Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
