Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 Oct 2014 01:10:07 +0400
From: Solar Designer <>
Subject: Re: passwdqc min= and enforce= should be quick questions

On Mon, Oct 27, 2014 at 04:18:23PM -0400, Dave Kalaluhi wrote:
> So on some newer systems we are using passwdqc via pam.d.
> The (not actual) settings are:
> min=5,5,5,5,5 similar=deny enforce=everyone
> Based on the man pages: with the above min settings, a password like
> passw should work. (unless I'm reading the man pages wrong).

You're probably not reading descriptions of options that you're not
using.  The match=N option by default (that is, when it is not
specified) implies additional checks:

             (default: match=4) The length of common substring required to
             conclude that a password is at least partially based on informa-
             tion found in a character string, or 0 to disable the substring
             search.  Note that the password will not be rejected once a weak
             substring is found; it will instead be subjected to the usual
             strength requirements with the weak substring partially dis-

             The substring search is case-insensitive and is able to detect
             and remove a common substring spelled backwards.


$ echo passw | pwqcheck -1 min=5,5,5,5,5 
Bad passphrase (based on a dictionary word and not a passphrase)
$ echo passw | pwqcheck -1 min=5,5,5,5,5 match=0

> pam/passwdqc doesn't allow that, and I'm assuming that's because of
> the enforce=everyone directive.

No, the enforce=everyone option only affects for whom the policy is
enforced, whereas your question is about the policy itself (whether a
password is considered weak or not).

> My question is, HOW passwdqc enforces passw is NOT a strong password.

I assume you mean how it "infers" that, not how it "enforces" anything.
(As I mentioned above, enforcement is a separate thing.)

It finds that "passw" has a 4-character common substring with the word
"pass", which is on its internal wordlist.  The default for substring
matching is match=4, which means that a 4-character match is considered
long enough to trigger this behavior.  The length of this substring is
then assumed to be one less than the minimum required for a match, thus
making it 3 characters, plus the "w" character.  That's an effective
password length of 3 + 1 = 4, which is less than your minimum of 5.
The reported reason is nevertheless what originally caused this sort of
checking, "based on a dictionary word and not a passphrase".

I strongly recommend that you don't alter passwdqc's default policy
unless you have a very important reason to do so.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.