If "3 of the following 4 properties - Uppercase,
smallercase, numbers, special-characters" are enforced, then a
dictionary attack is unlikely to work* and an attacker would need to
resort to a brute force approach.
Unless the attacker has additional knowledge about the password, with
3 of the properties enforced, he/she would have to include all upper
case, lower case, numbers and special characters to be certain that
the password will be found. As others have already mentioned, when a
brute force method is employed, password length is a more important
factor.
I would think that a higher level of security (than the current
configuration) would be reached by increasing the minimum password
length and ensuring that weak hashing is not used for caching/network
transmission of credentials than by spending time customising library
code (which could introduce new risks if mistakes are made) trying to
ensure that all 4 properties are enforced. The increased length would
of course have to be weighed against user inconvenience.
* Ansgar previously mentioned that b@n4Na could be still susceptible
to a dictionary attack with reference to user education. IMO, this
adds even more weight to the argument that password length should be
increased. I doubt that there are many 20 character examples
(complying with the existing password policy) that would be
susceptible.
On 8/16/07, John Wienand <JWienand@bna.com> wrote:
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
security.
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.
John Wienand
Network Services Manager
BNA Software
O: 202-496-6001 C: 202 329-1095
"Jackson,
Eric R IT3
(CVN75 To
CS-3)" "Ansgar -59cobalt-
<jackser@cv Wiechers"
n75.navy.mi <bugtraq@planetcobalt.net>
l> cc
Sent by: <focus-ms@securityfocus.co
listbounce@ m>
securityfoc Subject
us.com RE: Password complexity -
improvement
08/15/2007
06:46 PM
Ansgar,
You're absolutely wrong in your statement here. Enforcing
passwords
that MUST consist of uppercase letters, lowercase letter,
numbers AND
special characters INCREASES the total number of possible
passwords;
which in turn has a positive impact on your security.
It is much harder to break a password of AaBb1! than aabb1!
The more
options there are that are enforced, the more complex the
passwords.
The determining factor in this case would be how long or
short the
password lengths are.
R/
Jackson
-----Original Message-----
From: listbounce@securityfocus.com
[mailto:listbounce@securityfocus.com]
On Behalf Of Ansgar -59cobalt- Wiechers
Sent: Wednesday, August 15, 2007 2:39 PM
To: focus-ms@securityfocus.com
Subject: Re: Password complexity - improvement
On 2007-08-15 dubaisans dubai wrote:
Is there a way to improve the password complexity
requirements in
Windows 2000/2003 servers
The default will enforce 3 of the following 4 properties -
Uppercase,
smallercase, numbers, special-characters.
Is there a way to enforce all 4 properties.
Enforcing passwords that MUST consist of uppercase letters,
lowercase
letters, numbers AND special characters reduces the total
number of
possible passwords, which in consequence has a negative
impact on your
security.
Regards
Ansgar Wiechers
--
"All vulnerabilities deserve a public fear period prior to
patches
becoming available."
--Jason Coombs on Bugtraq
