Greg A. Woods wrote:

> Too bad it doesn't really address all of the underlying issues very well
> at all.  In fact I'd have to say the current implementation is basically
> a wet paper bag as opposed to what I provided originally.

Well, that's a lot nicer than what I have to say about passwords,
libcrack, and password policy enforcements with regard to how security
should be done. So? :)

> Don't get me wrong -- I agree with and like the structure of your
> solution, just not its very weak and incomplete set of options.

Luckily, pw_policy allows you to very easily add more options, so
just divert your writing energies to code instead of email.

> At the very least support for dictionaries must be added, and ideally
> they should of course be compatible with those crack (or something as
> good and as relevant) can generate.  This could very trivially be done
> by also including libcrack, just as my original solution offered.

If you give me one good reason why support for dictionaries is better
than nclasses/ntoggles, I'll add it.

> (conceptually libcrack also provides all the policy checks too, just not
> in such as configurable a way, and personally I lean much more to the
> Apple user interface goals when it comes to security -- the more
> options, the worse it is by far)

You'll have to convince someone else about importing libcrack; while
you're at it, also try to convince the same person that dictionary
support is as strong as the dictionary it uses.

Any other pw_policy improvements can be sent to me.

Thanks,

-e.

-- 
Elad Efrat
PGP Key ID: 0x666EB914