RE: Password complexity - improvement
- From: "Thor (Hammer of God)" <thor@xxxxxxxxxxxxxxx>
- Date: Fri, 17 Aug 2007 07:57:30 -0700
OK- time for "real world thinking" to be applied ;)
First off, Ansgar is completely correct - I was wrong to poke fun.
Requiring aspects of complexity does indeed limit the possible passwords
in that, say, "May I momma dogface to the banana patch?" could never be
While no restrictions on a password policy would always allow for mixed
case alphanumeric (and specials characters) to be used, having a policy
in place "forces" them to be used. In this case, the fact that you have
"reduced possible passwords" does not matter in the least, as all BF
efforts or rainbow table generation would *require* that all possible
combinations still be used since you don't know where in the phrase what
characters were being used. If the point is that you could "drop out"
certain characters strings while doing a BF or RT generation in the case
that you knew the password policy being used in order to speed up the
process, I would argue that generating the string, then looking at it to
see if it is complex enough to be hashed and compared would take longer
than just hashing and comparing in the first place.
That being said, forcing password complexity ensures that a minimum
keyspace be used (as opposed to just hoping) and thus has a positive
impact on security regardless of what "the math says" in regard to
reducing possible (and weaker) passphrases.
[mailto:listbounce@xxxxxxxxxxxxxxxxx] On Behalf Of John Wienand
Sent: Thursday, August 16, 2007 11:06 AM
To: Jackson, Eric R IT3 (CVN75 CS-3)
Cc: Ansgar -59cobalt- Wiechers; focus-ms@xxxxxxxxxxxxxxxxx;
Subject: RE: Password complexity - improvement
I think you are arguing two different points here.
One is the number of possible passwords and the other is
negative impacts on security.
He is correct when he says it reduces the number of
passwords, but incorrect when he says it diminishes
In the example you give below, if all four aspects are
enforced, then the second password could not be used. This
does in fact "reduce the number of possible passwords".
Another example would be the difference between requiring
that a password be exactly 8 characters in length, and
allowing a password to be any length up to 8 characters.
The latter would allow for a lot more possible combinations,
but does not remove the fact that a 1 character password is
not nearly as secure.
Just my 2 cents.
Network Services Manager
O: 202-496-6001 C: 202 329-1095
Eric R IT3
CS-3)" "Ansgar -59cobalt-
Sent by: <focus-ms@xxxxxxxxxxxxxxxx
us.com RE: Password complexity -
You're absolutely wrong in your statement here. Enforcing
that MUST consist of uppercase letters, lowercase letter,
special characters INCREASES the total number of possible
which in turn has a positive impact on your security.
It is much harder to break a password of AaBb1! than aabb1!
options there are that are enforced, the more complex the
The determining factor in this case would be how long or
password lengths are.
On Behalf Of Ansgar -59cobalt- Wiechers
Sent: Wednesday, August 15, 2007 2:39 PM
Subject: Re: Password complexity - improvement
On 2007-08-15 dubaisans dubai wrote:
Is there a way to improve the password complexityrequirements in
Windows 2000/2003 serversUppercase,
The default will enforce 3 of the following 4 properties -
smallercase, numbers, special-characters.
Is there a way to enforce all 4 properties.
Enforcing passwords that MUST consist of uppercase letters,
letters, numbers AND special characters reduces the total
possible passwords, which in consequence has a negative
impact on your
"All vulnerabilities deserve a public fear period prior to
--Jason Coombs on Bugtraq
- Prev by Date: Re: Password complexity - improvement
- Next by Date: RE: Password complexity - improvement (correction)
- Previous by thread: Re: Password complexity - improvement
- Next by thread: RE: Password complexity - improvement