[Pkg-shadow-devel] Bug#443322: login: immediate 'Login incorrect' after unknown user name

[Steve Langasek]

On Sun, Aug 24, 2008 at 03:01:41PM +0200, Nicolas François wrote:

> On Sat, Aug 23, 2008 at 10:30:59PM -0700, vorlon at debian.org wrote:
> > I just upgraded one of my sid machines that had a modified /etc/pam.d/login,
> > and was quite surprised to see the conffile prompt from this change,
> > specifically because of the use of pam_faildelay.

> > Did you consider doing this instead for pam_securetty?:

> > auth	[success=ok user_unknown=ignore default=die] pam_securetty.so

> I did not added this because in case of an insecure TTY, if root enters
> his name with a typo, she will be prompted for a password.
> (That was my true in my last try: the user is checked before the TTY)

True, but I'm not convinced this is actually a problem; in order for the
user to shoot themselves in the foot, they must:

- be running login on an insecure tty (...seriously?  who still runs telnet
  anymore, unless it's kerberized telnet?)
- mistype the name "root"
- fail to *notice* they've mistyped the name "root", and then proceed to
  type the root password.

Is that really a case that's worth protecting against?  Isn't it just as
likely that a user will type in a *correct* username, and then make the
mistake of typing the root password instead of the user password?

> There are in fact two contradicting requests on insecure TTYs
>  * if the user is unknown, the password prompt should not be displayed (it
>    might be a typo for root)
>  * the password prompt should always be displayed to avoid giving
>    an indication that the user does not exist.

> I'm not sure which one is the most critical.

I don't know either, but the previous behavior was consistent for the better
part of a decade, so I think it would be preferable to have such a change
discussed more widely (= debian-devel) before committing to it in a release.

(I'm not happy with the new behavior of pam_securetty, myself, but I'm not
going to diverge from the upstream change when we can work around it in the
config as described above.)

> > Not sure if that should be considered any better, but it avoids needing to
> > add another module to the stack.  (One which isn't very well documented, if
> > I do say so myself!)

> The additional pam_faildelay module replaces a call to pam_fail_delay()
> which was removed from login (this was done to avoid hardcoding a delay in
> login (it was in fact in login.defs), which was disturbing for user
> willing to reduce the delay in login.defs, or to remove the delay by
> adding nodelay to pam_unix).

> Would it be better to call pam_faildelay only in case of a pam_securetty
> failure, and otherwise let pam_unix set the delay?

All in all, I think that calling pam_faildelay is appropriate because there
are authentication modules one might use in place of pam_unix which do *not*
call pam_fail_delay at all (e.g., pam_krb5 and pam_ldap).  I'm just not sure
that /etc/pam.d/login is the right place for it, or if it actually belongs
in /etc/pam.d/common-auth.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org