cracklib dicts size (and fedora password policy)

[Kurt Seifried]

On Tue, Sep 17, 2013 at 8:01 AM, Miloslav Trmač <mitr at volny.cz> wrote:

> On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm at fedoraproject.org>
> wrote:
> > Meanwhile, in many systems today, local passwords are entirely unused.
> > Authentication is done via keys or by kerberos.
> >
> > At the same time, we have an increased need for smaller systems. That 8MB
> > starts to be a meaningful fraction of a container or an ultra-small cloud
> > image
>
> 1) Is the "need for smaller systems" really such an issue?  I've seen
> quite a few such requests recently, and in almost all cases it seems
> that just sharing the storage would solve all of these problems at
> once, at a totally much lower cost than trying to shave a megabyte
> here or there.
>

The use case for this is often IaaS/PaaS style cloud providing so you have
many different clients so shjared storage probably isn't super safe, plus
you have the clients creating and uploading their own images, often based
off of the JEOS (Just Enough OS) images, so shared storage wouldn't help
there. Fancy deduplication would help, but the blocks would need to be
aligned/etc.


>
> 2) A typical "application separation container" should, IMHO, not even
> have a password database used for management, let alone a login shell.
>  (Just launch a shell process and attach it into the container.)  So,
> in that case, the database should be removed, not made smaller.  Right
> now that would mean removing all of PAM, which is somewhat problematic
> (if the application uses PAM to authenticate access to the
> application.).
>

Well there's the world we should have, and the world we actually have. I'm
still assigning a lot of CVE's for /tmp vulns, in 2013. /tmp vulns should
not be a problem anymore, and yet programmers keep messing it up. Plus some
people legitimately need logins/local passwords/etc, so to simply say "yeah
to bad we don't support that" kind of sucks/isn't workable.


3) For both virtualization and virt-like containers that accept
> authentication by "keys or kerberos", wouldn't it make most sense to
> disable password authentication altogether, then?
>

See above answer.


> If 1) is false, 2) and 3) suggest to me that this might be best solved
> by packaging the "password creation/change functionality" as an
> optional component (encompassing libpwquality+cracklib*+perhaps some
> parts of PAM), installed by default in @core, that the ultra-small
> setups could just remove (and if they were missing, creating/changing
> passwords would have to fail).
>

How does one log into the image to make changes? not everyone will be able
to easily manage/modify the JEOS images using tools, so again you just
excluded a large chunk of people from using them. I think logging into an
image via SSH is a pretty common feature/requirement and we should continue
to support it.


> As for reducing the dictionary size: Ideally, the dictionary would be
> there only to protect against off-line attack when someone stole the
> password file.  (Note that such cases are _more_ likely in the cloud
> paradigm, where all disk images are stored together.); for on-line
> attacks there would be an efficient lockout mechanism, or at least
> rate limiting.  However we don't have either available by default due
> to risk of a DoS.
>

Yup.


> So, we _do_ rely on the strength of the password against on-line
> brute-forcing.  We even allow root to ssh in by default!  In this
> environment, allowing the user to use a slightly-obscure word that is
> nevertheless certainly present in the attackers' dictionaries is
> irresponsible.
>

At some level we need to start trusting the user to do the right thing, we
can't bubble wrap the entire world. We also have to let the user do
potentially dangerous things (like root logins) because again there are
often legitimate requirements for this.


> (Now, that might divert the topic into the separate discussion of ssh
> enabled by default, but that's beside the point.)
>
>
> Best as I can tell, the only reasonable practice for password use is:
> * Have very few passwords that need to be remembered by a human.  (For
> the others, autogenerate something completely random and store them in
> an encrypted keyring, within Firefox, the OS, or anywhere else.)
> * Make those few passwords that need to be remembered rather strong,
> with a good security margin.
>

Or do smart things like Google's 1 factor auth where logging in from a new
device/IP triggers them to ask for additional info like your phone # you
used when registering, etc. Not as easy with SSH though =(.


>
> We don't have all the pieces to make such a password use really easy
> (e.g. Firefox offering the user to generate new passwords) right now -
> but making the dictionaries weaker does seem to go in the wrong
> direction.
>     Mirek
>

I'm not sure having the dictionaries at all really helps, and the people
using JEOS are (hopfully) a bit more clued in than the average user who
pops a Linux CD into the laptop to install and see what it's all about =).
I do know that having the ability to SSH in and tweak things is pretty
critical.


>
> On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm at fedoraproject.org>
> wrote:
> > The cracklib dicts in Fedora is 8.3M. (I'm sure some of this is my
> fault, as
> > I've added to it over the years.) The cracklib pam module supports a
> > compressed dictionary, but apparently it has a serious performance impact
> > (https://bugzilla.redhat.com/show_bug.cgi?id=1004896).
> >
> > Meanwhile, in many systems today, local passwords are entirely unused.
> > Authentication is done via keys or by kerberos.
> >
> > At the same time, we have an increased need for smaller systems. That 8MB
> > starts to be a meaningful fraction of a container or an ultra-small cloud
> > image.
> >
> > I do recognize the value of protecting against dictionary-based attacks
> when
> > passwords are used. Maybe we could have a policy which requires _longer_
> > passwords but uses a much smaller dictionary?
> >
> > --
> > Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <
> mattdm at fedoraproject.org>
> > --
> > security mailing list
> > security at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/security
> --
> security mailing list
> security at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/security




-- 
Kurt Seifried
kurt at seifried.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/security/attachments/20130917/1386e308/attachment.html>