8:04 a.m.
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(a)fedoraproject.org>
8:08 a.m.
On Fri, 2013-09-06 at 09:04 -0400, Matthew Miller 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?
The other option would be to fix the gzip support in cracklib to cache
the unpacked data somehow. However that would require to keep the
unpacked dictionary in RAM when cracklib is loaded, which is suboptimal
as well. Or we could make the cracklib-dicts optional somehow so it is
possible to install an ultra small cloud image without the dictionary at
all - I expect ultra small cloud image not needing password quality
checking at all.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
8:17 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/06/2013 09:08 AM, Tomas Mraz wrote:
On Fri, 2013-09-06 at 09:04 -0400, Matthew Miller 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?
The other option would be to fix the gzip support in cracklib to cache the
unpacked data somehow. However that would require to keep the unpacked
dictionary in RAM when cracklib is loaded, which is suboptimal as well. Or
we could make the cracklib-dicts optional somehow so it is possible to
install an ultra small cloud image without the dictionary at all - I expect
ultra small cloud image not needing password quality checking at all.
Could anaconda decompress the file to another location to fix their problem.
Then we ship it compressed? I am willing to wait an extra 10 seconds while
changing my password which I do very seldom. Maybe have the library look for a
decompressed file first and fail over the the compressed one. Then admins could
decompress it if they see this as a problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlIp1fgACgkQrlYvE4MpobONMQCdESTx4Yh13iMjJrtkjobelicw
DMAAoKw+nlaJQ7VrTxQRg64nIMjabqq+
=BZkE
-----END PGP SIGNATURE-----
8:20 a.m.
On Fri, Sep 06, 2013 at 03:08:54PM +0200, Tomas Mraz wrote:
The other option would be to fix the gzip support in cracklib to
cache
the unpacked data somehow. However that would require to keep the
unpacked dictionary in RAM when cracklib is loaded, which is suboptimal
as well. Or we could make the cracklib-dicts optional somehow so it is
possible to install an ultra small cloud image without the dictionary at
all - I expect ultra small cloud image not needing password quality
checking at all.
Yes, that's https://bugzilla.redhat.com/show_bug.cgi?id=865521 :)
"Optional somehow" is easy -- make "cracklib-dicts-full" and
"cracklib-dicts-small" and make them both provide "cracklib-dicts".
(The small could consist of some list of N most common passwords, plus
N most common words in N languages, where all of the Ns are chosen to keep
the filesize to 100k or so.)
Somewhat ironically, I bet we could compress that 100k without much of a
performance hit, too. :)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:25 a.m.
On Fri, Sep 06, 2013 at 03:08:54PM +0200, Tomas Mraz wrote:
On Fri, 2013-09-06 at 09:04 -0400, Matthew Miller 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?
The other option would be to fix the gzip support in cracklib to cache
the unpacked data somehow. However that would require to keep the
unpacked dictionary in RAM when cracklib is loaded, which is suboptimal
as well. Or we could make the cracklib-dicts optional somehow so it is
possible to install an ultra small cloud image without the dictionary at
all - I expect ultra small cloud image not needing password quality
checking at all.
As an unscientific test, I looked at how long it takes to decompress
the file pw_dict.pwd file with gzip
# gzip -c -9 /usr/share/cracklib/pw_dict.pwd > pw_dict.pwd.gz
# echo 2 > /proc/sys/vm/drop_caches
# time gunzip -c pw_dict.pwd.gz > pw_dict.pwd
real 0m0.112s
user 0m0.104s
sys 0m0.007s
IOW, AFAICT, decompression time of pw_dict.pwd should not even be
noticable, unless it is decompressing it multiple times during a
single password change operation ? Even then it would have to be
decompressing it at least 10 times to become really noticable.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
8:34 a.m.
On Fri, 2013-09-06 at 14:25 +0100, Daniel P. Berrange wrote:
On Fri, Sep 06, 2013 at 03:08:54PM +0200, Tomas Mraz wrote:
> On Fri, 2013-09-06 at 09:04 -0400, Matthew Miller 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?
>
> The other option would be to fix the gzip support in cracklib to cache
> the unpacked data somehow. However that would require to keep the
> unpacked dictionary in RAM when cracklib is loaded, which is suboptimal
> as well. Or we could make the cracklib-dicts optional somehow so it is
> possible to install an ultra small cloud image without the dictionary at
> all - I expect ultra small cloud image not needing password quality
> checking at all.
As an unscientific test, I looked at how long it takes to decompress
the file pw_dict.pwd file with gzip
# gzip -c -9 /usr/share/cracklib/pw_dict.pwd > pw_dict.pwd.gz
# echo 2 > /proc/sys/vm/drop_caches
# time gunzip -c pw_dict.pwd.gz > pw_dict.pwd
real 0m0.112s
user 0m0.104s
sys 0m0.007s
IOW, AFAICT, decompression time of pw_dict.pwd should not even be
noticable, unless it is decompressing it multiple times during a
single password change operation ? Even then it would have to be
decompressing it at least 10 times to become really noticable.
I am afraid that is the case and that it is doing it even more times
than that. So there is definitely possibility to fix the compressed
dictionary support to uncompress, cache and use the cache. However I
cannot work on this just now but I am taking patches :)
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
8:19 a.m.
On Fri, Sep 06, 2013 at 09:04:34AM -0400, Matthew Miller 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).
That's an odd bug report - decompressing a mere 8 MB file really shouldn't
have as high a penalty as the bug suggests. Sounds like perhaps there is
a perf problem in cracklib that could be usefully fixed here, rather than
just closing the bug saying compression is unusable. It might also be worth
trying lzop, which IIRC has much better decompression performance than gzip,
albeit with slightly worse size.
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?
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 ?
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
8:43 a.m.
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.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
12:30 p.m.
On 6 September 2013 07:43, Matthew Miller <mattdm(a)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.
12:56 p.m.
On Fri, Sep 06, 2013 at 11:30:30AM -0600, Stephen John Smoogen wrote:
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).
What I was thinking was a 16-character configuration if the cracklib dict
isn't installed or is small, and the current 8-character configuration
otherwise. Maybe this is silly.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
1:47 p.m.
-----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(a)fedoraproject.org <mailto:mattdm@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-----
2:05 p.m.
On Fri, Sep 06, 2013 at 12:47:25PM -0600, Kurt Seifried wrote:
TLDR; I guess my concern is diminishing returns from the dictionary
check for password files, assuming it works at all.
This argues for replacing the existing large wordlist with a shorter one and
calling it a day.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
9:01 a.m.
On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm(a)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.
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(a)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(a)fedoraproject.org>
--
security mailing list
security(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security
11:10 a.m.
On Tue, Sep 17, 2013 at 8:01 AM, Miloslav Trmač <mitr(a)volny.cz> wrote:
On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller
<mattdm(a)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(a)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(a)fedoraproject.org>
> --
> security mailing list
> security(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/security
--
security mailing list
security(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security
--
Kurt Seifried
kurt(a)seifried.org
8:10 a.m.
On Tue, Sep 17, 2013 at 6:10 PM, Kurt Seifried <kurt(a)seifried.org> wrote:
On Tue, Sep 17, 2013 at 8:01 AM, Miloslav Trmač <mitr(a)volny.cz>
wrote:
>
> On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm(a)fedoraproject.org>
> wrote:
> 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.
Well,
sure.
> 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?
See 2) above - create a process, attach it into the container, then
exec a shell. This requires privileges on the server, but not within
the container.
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.
Yes, definitely - for the distribution default. The JEOS case is
already deviating from defaults, by definition.
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 =).
Right, but we are not _yet_ in the multi-product world where we can
easily tailor the cloud image for a different user audience to this
extent.
Mirek
3869
days inactive
3883
days old
security@lists.fedoraproject.org
14 comments
9 participants
participants (9)
-
Daniel J Walsh -
Daniel P. Berrange -
Kurt Seifried -
Kurt Seifried -
Matthew Miller -
Matthew Miller -
Miloslav Trmač -
Stephen John Smoogen -
Tomas Mraz