[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#364526: debian-installer: Please implement a password-checking module

(Please send mails to -submitter so I can actually see them, I'm the
originator of this bug but I'm not subscribed to debian-boot)

Joey, the cracklib2 library, IIRC, does not check for password robustness
(i.e. size, use of characters, etc.) but, actually, tries to crack it using
its dictionary. This prevents people from entering, for example 'debian' or
'debian123', as a password. Including it in d-i (as I suggested) would mean
providing a dictionary for cracklib's (in installed systems it is available
at /var/cache/cracklib/ and generated from from the local dictionaries being
installed) which could be rather large: 820K in my local filesystem based on 
the 1,7M dictionary files I have installed (including spanish and english

The libpam-passwdqc module, however, when stacked in /etc/pam.d/passwd, will
do both the cracklib2 checks *and* checks for password robustness (minimum
length, character sets in the password, etc).

If we want to go that way I suggest we do what Owl's installer does [1]:

- have PAM be configured to use libpam-passwdqc per default in any Debian

- have d-i install some common dictionaries, libpam-passwdqc and cracklib2 at the target system
  (that way Cracklib's dictionary will be generated there)

- chroot to it and use PAM to set the root/user password (see
  pam_root_password [2])

- let PAM tell us if the password is valid or not.

This could be done *in*addition* to some simple checks done in the installer
itself, as I suggested initially and Masami Ichikawa implemented, as long as
the checks done in d-i are consistent with libpam-passwdqc's configuration.

This has the advantage that password checking would be a standard setup in
any Debian system, regardless of whether the password is set on d-i or it's
changed later. And would actually apply to all users (not only those
configured through the d-i).

It has the disadvantadge that is a major change that implies changes in other
packages (PAM's default configuration) and significant coding (although this
could be simplified if reusing Owl's code [3], which is already available)

Another (different way) that could be implemented as an alternative 
would be to:

- have d-i provide the cracklib-runtime + libcracklib2 + a proper (pregenerated)
  dictionary (note the size increase, as described above)

- do some basic password checks within d-i (with the patch provided in this

- use the 'crack_testlib' binary to run a test on the password and let the
  user know if the password is based on a dictionary password.

That would be easier to code and has the advantage that no other changes are
needed (to PAM) but it has the disadvantages that the d-i size increases
(which is an issue currently) and is also duplicating code (as the password
checking code is already present in libpam-passwdqc, which we are not using
in this case)

Hope that helps clarify stuff,




[3] The .spec file claims It's BSD-licensed, but it would be nice to ask
Solar Designer to add proper licenses to the headers of all the files in
there, to avoid any licensing confusion with it.

Attachment: signature.asc
Description: Digital signature

Reply to: