add passwdqc support to systemd-homed

[shaba]

Please, add passwdqc (https://www.openwall.com/passwdqc/) support as option like pwquality.
LUKS can build with passwdqc support.

[poettering]

hmm, are there any distros that make use of that? why is this preferable over libpwquality?

[shaba]

ALT Linux used passwdqc since 2001 (https://packages.altlinux.org/en/sisyphus/srpms/passwdqc/changelogs)
@ldv-alt can better explain the reason for using passwdqc.

[poettering]

Is that the only distro? Why not switch over to libpwquality?

I mean, I am not to keen on supporting a myriad of options there, in particular if it's not something used in big mainstream distros.

[bonktree]

A lot of popular distros include passwdqc and its corresponding PAM module as an option for password quality checking: Debian/Ubuntu, SuSE. Debian in particular offers packages for both and offers neither in its default installation.
As homed in particular and systemd as a whole are actively used over there, it's important for us to be diverse in this regard.

[poettering]

including is one thing. what about enabling it by default? that's mostly what i care about. fedora/rh based distros all enable libpwquality by default.

[ldv-alt]

On Tue, Mar 31, 2020 at 08:52:59AM -0700, Alexey Shabalin wrote: ALT Linux used passwdqc since 2001 (https://packages.altlinux.org/en/sisyphus/srpms/passwdqc/changelogs) @ldv-alt can better explain the reason for using passwdqc.

The reason is obvious: passwdqc works better, it's smaller and faster than libpwquality+cracklib. See also this historic post: https://twitter.com/solardiz/status/792177246584832000

[ldv-alt]

On Tue, Mar 31, 2020 at 09:34:13AM -0700, Lennart Poettering wrote: including is one thing. what about enabling it by default? that's mostly what i care about. fedora/rh based distros all enable libpwquality by default.

The reason why RH chose libpwquality+cracklib over passwdqc was likely not very technical, see e.g. this historic discussion: https://twitter.com/solardiz/status/411242049107943424

[ldv-alt]

On Tue, Mar 31, 2020 at 09:49:27AM -0700, Dmitry V. Levin wrote: On Tue, Mar 31, 2020 at 08:52:59AM -0700, Alexey Shabalin wrote: > ALT Linux used passwdqc since 2001 (https://packages.altlinux.org/en/sisyphus/srpms/passwdqc/changelogs) > @ldv-alt can better explain the reason for using passwdqc. The reason is obvious: passwdqc works better, it's smaller and faster than libpwquality+cracklib. See also this historic post: https://twitter.com/solardiz/status/792177246584832000

And this one: https://twitter.com/solardiz/status/411406337927815168

[Zlogene]

@poettering in gentoo we also prefer passwdqc over pwquality by default), pretty much for the reason @ldv-alt mentioned.

[poettering]

hmm, the way i read it noone posted any reason here besides "i like apples better than bananas"... "better", "faster", "smaller" is so vague it couldn't be anymore vague...

But anyway, if you care about this, send a PR (ideally done via dlopen(), as in #16260 or #16145)

[solardiz]

@poettering I agree the tweets of mine that @ldv-alt referenced are not convincing on their own. Please refer to this third-party comparison of 5 tools, including passwdqc and pwquality:

https://www.slideshare.net/antondedov5/zn2013-testing-of-password-policy-abridged

Slide 23 shows passwdqc miss the fewest weak passwords (crackable in that study's specific attacks), at 0.5%, and pwquality miss the most of those, at over 2%, with the remaining 3 tools staying inbetween.

Slide 25 shows passwdqc and pwquality being equally willing to accept typical not-too-weak passwords that users want to use.

Slides 26 and 27 show pwquality unnecessarily reject most strong passwords that were left uncracked in the Crack Me If You Can 2010 contest (pwquality accepts only 10% of those; passwdqc accepts 60%). They also show pwquality unnecessarily reject almost 20% of randomly-generated 10-character passwords, whereas passwdqc accepts all of those.

Slide 32 shows that pwquality is the slowest of the 5 tools compared, being 13x slower than passwdqc.

There are also some results from the same author at:

http://password-policy-testing.wikidot.com/results

[solardiz]

Correction: the slide 23 percentage figures quoted above are on a weird scale of up to 300% (since percentages for 3 password sets were added together rather than averaged), so the actual ones would be 3x lower - thus, ~0.17% vs. ~0.7%.

The 4x ratio between the two tools holds regardless of scale. So it can be said that with the tested settings pwquality results in 4x more crackable passwords while not being friendlier in terms of accepting desirable strong-enough passwords.