[Pkg-shadow-devel] Bug#443322: login: immediate 'Login incorrect' after unknown user name
vorlon at debian.org
Mon Aug 25 06:25:20 UTC 2008
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
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
More information about the Pkg-shadow-devel