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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ansgar -59cobalt- > Wiechers > Sent: Thursday, August 16, 2007 11:08 AM > To: [email protected] > 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 "[EMAIL PROTECTED]" 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
