cracklib dicts size (and fedora password policy)

[Kurt Seifried]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/06/2013 11:30 AM, Stephen John Smoogen wrote:
> 
> 
> 
> On 6 September 2013 07:43, Matthew Miller
> <mattdm at fedoraproject.org <mailto: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.

I think one thing to consider is the kind of person that would want to
use a password instead of kerberos/ssh keys/etc.:

1) They know what they're doing and will create secure passwords
regardless of what we allow (e.g. using pwgen).

2) They won't create secure passwords, the question then becomes what
is the best way to encourage good passwords? minimum password length?
password dictionary? calculate the entropy possible with their
password and tell them? E.g.:

"you used lower case and numbers, so that's 36 characters, it's 8 long
so that's about 41 bits of entropy assuming totally random
distribution (HAH! like that'll happen), assuming normal humanness in
picking stuff it's more like 30 bits (or whatever) meaning it'll be
easy for an attacker to compromise. Please pick a better password or
hit "Y" to accept"

Thus allowing them to make a better informed decision.

But I really wonder how much this matters? E.g. unless you pick a
really bad password (god, sex, power?), or reuse passwords the chances
of brute forcing attacks working should be low, my main concern would
be people reusing passwords on systems (e.g. web forums) that don't
securely store them, the forum gets popped, the passwords are revealed
and the attacker has a new dictionary of passwords to try (plus
probably usernames and IP addresses from whence they came).

TLDR; I guess my concern is diminishing returns from the dictionary
check for password files, assuming it works at all.


- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSKiM9AAoJEBYNRVNeJnmTYAcQAJtmTMQhmpi/4C2ZAiKvEssY
xPPj8jb+TV6EO6Y7b9o17xH3KSnxryLUAH87nVzZb/OJ1vQFG4cP29WrFBVMq0Ai
A2U+mqUqe37iAuNOKzcDBPn/9E8w85Z4Jju2z2JHQTVbrOcz+phxglQ4jC8dMDun
a7xpwuOSM4VPYcs1L//9RkF2hjYXAqLBo+okmN3L7kPORfhtJqBrgPBntqxeSHwQ
Z33o9E7qXZ3Re6gkEbAgFabAOnAtlcVc5Ds0KG6W+N6WGyglA9SvZUDqkarwe8w6
IDAzzkSn/W9F26Q4tvHiW1UMSQq0WTlXkls5sHe9f/UsLw9tt9Z2g1upvOc6dwX/
qqIGXygVJVaTTnsVzHsypI/J7huJyh69DIXh8zcqH7FZKqjRumgaWrgU8y9aF+xp
Xo0M4fkg4WxBuNNes3tZ1fWG2AlWU7zWVQoRwnPp/LLU/C9CB7PYsp2q3XhaqaAP
AFhFkG3V4Vf6B5EM4uRSvGDDmv/H2PB1CZ2ecN0frjCnuYgnjpH7eyVIXOCvR+w9
APNfeaszJLp0hMWSl+Vch/O5K+ctIoqWQfPR33tTnohviSCbMwWHzCEjRlWB0EhB
XNR1HFWrVVn4/Q8w/VHET0Q2nSivzTOcGdtQL01wu9qd0fPL/XyG/bIOX7TZBBmz
IcT/qaxHqFhrflUNi79E
=hW8h
-----END PGP SIGNATURE-----