On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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.
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.).
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?
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).
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.
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.
(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.
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
On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx>
> --
> security mailing list
> security@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/security
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
