cracklib dicts size (and fedora password policy)

[Tomas Mraz]

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.)