Re: Delays

["Michael K. Johnson" <johnsonm redhat com>]

Marek Michalkiewicz writes:
>- I think the main purpose of delays was to slow down password
>  guessing attempts, so it should be OK to do it in the pam_unix
>  module, other authentication methods probably don't need them.

Passwords are not restricted to the pam_unix modules.  Just because
most of the other modules currently available don't have anything to
do with passwords doesn't mean that we should ignore the possibility
of others having passwords later.  For instance, the kerberos and
s/key modules will work with passwords.

>- I know it is more "pluggable" to make a separate delay module,
>  but if we have so many modules for every little thing, loading
>  every such module has its overhead...

Overhead is hardly a problem for a delay module, is it?

>I vote for delays built in the pam_unix module.  Maybe we should see
>what Sun did?  Solaris has PAM (as a "private internal interface",
>according to the RFC) since release 2.3, and they do delays on login
>failures for all services by default, so I think they probably have
>already solved this problem somehow.

Hm.  Sounds like they implemented it in their version of libpam.
That's a possibility, but I prefer to give the sysadmin the control
over the policy.  Isn't that one of the goals of PAM?  I know sysadmins
who type fast and wild who generally take 5 attempts to log in
successfully; they would probably strongly desire to tune the delays.
On the other hand, you can probably tell by examining the source code
for vlock that I believe in delays, and would want to configure some
real delays into my own system, likely more stringent than the delays
that might be included in the code otherwise.

I proposed one system that would provide the sysadmin plenty of
flexibility; as long as the sysadmin retains control, I don't care
too much how it's done, within reason.

michaelkjohnson

"Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"