cracklib dicts size (and fedora password policy)

[Stephen John Smoogen]

On 6 September 2013 07:43, Matthew Miller <mattdm at fedoraproject.org> wrote:

> On Fri, Sep 06, 2013 at 02:19:16PM +0100, Daniel P. Berrange wrote:
> > > passwords are used. Maybe we could have a policy which requires
> _longer_
> > > passwords but uses a much smaller dictionary?
> > Or by default require that every password have at least one
> non-alphanumeric
> > character in it, at which point it'll never match a regular dictionary
> > entry ?
>
>
> I don't think that buys a whole lot, since dictionary-based attacks do the
> simple transforms and character additions people usually do to get around
> such checks.
>
>   $ echo password1 | /usr/sbin/cracklib-check
>   password1: it is based on a dictionary word
>
> ("password" remains the most popular password of all, but "password1" is
> right up there.)
>
> This is why I suggest length. NIST password guidelines
> (http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf, go
> to
> page 107) suggest that a 16-character (probably all lowercase) password
> with
> no checks is as strong as a 8-character password with dictionary check plus
> character set rules.
>
>
>
I am all for 16+ character passwords, but what you get is qazwsxedcrfvtgb
versus injureCarpRoast. And then you get a TON of backlash on how hard it
is to create a 16 character password that they can remember. Doing our
weaker Fedora password rules of 9->12] was enough for me to realize that
the amount of pushback one gets from even 'security minded' people. My
first question would be is the 8MB worth the pain of that OR would a better
solution for ultra-small installations is a kickstart %post scriptlet which
does the config that is needed to not have a cracklib installed (because
any ultrasmall installation is going to need a lot of scriptlets).

-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/security/attachments/20130906/2d35aad0/attachment.html>