[Owasp-leaders] Password complexity guidance

Yvan Boily yvanboily at gmail.com
Wed Dec 11 20:55:35 UTC 2013

I disagree; we should make the argument for the best security.  We can
still make the recommendation for a stronger security control, but should
include recommendations for users that are blocked by technical
limitations.  If we position recommendations in the context of what is
best, with current limitations, it leaves individuals who are looking at
that guidance with the impression that there is nothing better that can be

Also, just did some reading, and adding support for more useful password
complexity options seems fairly straightforward according to the
documentation on MSDN[1], so part of the platform specific recommendation
should include deploying a password filter.

[1] -

On Wed, Dec 11, 2013 at 11:14 AM, Josh Sokol <josh.sokol at owasp.org> wrote:

> We've been discussing this quite a bit lately at work due to the
> federation of internal identities to cloud-based applications.  Obviously,
> best practice is to use some sort of multi-factor authentication so that a
> password alone isn't the only defense.  That said, where time, money, or
> other issues prevent you from doing more than just "something you know"
> authentication, I agree that passphrases are probably better, but the devil
> is in the details.
> Take Microsoft Active Directory for example.  Your options for passwords
> basically boils down to two things: 1) Length and 2) Complexity.  In terms
> of complexity, it's a check box.  You either have it enabled as a policy or
> you do not.  When enabled, you can't guarantee random, but at least you can
> guarantee a larger character set because you have to have at least three of
> the four of upper, lower, digits, and special characters.  When disabled,
> however, like you'd probably want to do for passphrases like "correct horse
> battery staple" (all lower case words plus space character, no upper, no
> digits), you no longer have the policy in place to prevent stupid passwords
> like "password" or "passwordpassword" or "password12345678...."
> So, while I agree with what you're saying, that passphrases are easier to
> remember and ideally just as secure, I wouldn't issue any sort of guidance
> on that until validation technologies exist to actually enforce secure
> passphrases just like they already exist to enforce secure passwords.  Make
> sense?
> ~josh
> On Wed, Dec 11, 2013 at 12:43 PM, Michael Coates <michael.coates at owasp.org
> > wrote:
>> We have two references (and probably more - please send if you see more)
>> for password complexity.
>> https://www.owasp.org/index.php/Password_length_%26_complexity
>> https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Proper_Password_Strength_Controls
>> First - I agree passwords alone need to die. It's not sufficient. But
>> that said, passwords will be around until the next solution is ready. So,
>> in the interim we should provide the best guidance on selecting good
>> passwords.
>> I no longer agree with the approach of forcing users to select gibberish
>> passwords. I believe that passphrases are much better. They achieve great
>> entropy and are far easier for users to remember. My initial position is we
>> should shift our guidance away from the old complex recommendation to a
>> passphrase recommendation.
>> Agree? Disagree? Interested in your thoughts.
>> Whatever we do select, we should make sure we cross link so we don't have
>> multiple sources of information that could be out of date.
>> --
>> Michael Coates
>> @_mwc
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20131211/c8d099b5/attachment-0001.html>

More information about the OWASP-Leaders mailing list