First some background:
Anaconda 22.17+ has started to enforce the following:
+- Don't allow weak LUKS passwords either (bcl)
+- Don't allow weak passwords (text mode). (sbueno+anaconda)
+- Remove the press done twice to exit text (bcl)
+- Don't allow weak user passwords (bcl)
test@ list 1st announcement of change, and the ensuing 91 (and
counting) email thread which you're welcome to skip as I'll attempt to
cover the salient points in this email:
The impetus behind the change are the two scope bullets in this rejected change:
A FESCO ticket has been opened asking for review:
And then some points:
- I think it'll make users angry. The test@ list is overwhelmingly
against the change, and I expect they're more tolerant and
understanding compared to the wider community.
- On Windows and OS X server variants, remote access (in-bound)
services are disabled by default. It's expected to use an OOB method
to initially connect to a server (or even VM) and enable the desired
- libpwquality is what's being used to "grade" the quality of the
passwords used in anaconda. This has been referred to as having
capricious behavior in the test@ thread. In a 2 day old build of
boot.iso which contains the current version of libpwquality and
anaconda 22.17, I'm finding the following:
The gibberish password that an infamous xkcd comic strip railed against
8 actually random lowercase latin characters.
8 random characters mixed case, numbers, specials.
Portions of widely published phrases, lowercase latin characters.
I don't have an easy way to prove this, but in a millions+ attempt
brute force attack, I find it difficult to believe that
correcthorsebatterystaple is not attempted, but 6*T!MsjD is attempted.
I had recently read that up to 100 character dictionary only word
based passwords were routinely attempted in brute force attacks.
I think the change improperly shifts burden to all users without
respect to their use case, in a manner inconsistent with the device
control they've come to expect: no password requirements at all on
mobile devices, and very minimalist ones on Windows and OS X. I don't
see how being an outliar in this area, even among Linux distros,
Conclusion: I think the concerning services need to be disabled by
default, and use OOB management to enable those services, since it's a
long standing practice elsewhere. If we can do better than this, fine,
but not by shifting the security burden.