Pasword quality pluggable interface project review

Nicolas Williams Nicolas.Williams at
Mon Aug 30 15:56:58 EDT 2010

On Mon, Aug 30, 2010 at 12:41:55PM -0700, Russ Allbery wrote:
> Nicolas Williams <Nicolas.Williams at> writes:
> >  - quality check requires more inputs:
> >     - the KDB entry, specifically, so the password quality module can
> >       check the user's password history
> I wouldn't externalize this into a module, personally, due to the
> instability in the KDB structures.

Maybe it's time to provide a stable, extensible KDB interface.
Alternatively, the password history check will have to be an internal
function, not a plugin (though perhaps masquerading as a special

> >     (and maybe other things, such as user's languages, so that
> >     dictionary checks can be done for all the languages the user speaks)
> That would be a very bad idea for a password quality check.  To prevent a
> password guessing attack, the language of the user is irrelevant.  You
> care about the language of the attacker, or rather, what dictionaries the
> attacker has.  Therefore, the only safe assumption is to assume that the
> attacker will check all languages, and you should do the same thing.

Good point.  I agree that you want to check as large a dictionary as you
can (today most systems check an English dictionary only).  I'm not sure
that there's no case where knowing the languages spoken by the user
wouldn't help though, since different languages might require different
preparatory steps prior to checking a dictionary.  Although thinking
about it more, I think it may suffice to just know the encoding of the
new password (which should always be UTF-8), then the checker can
inspect it for scripts it uses and do whatever prep steps are needed
prior to checking a dictionary.


More information about the krbdev mailing list