Bug 119874

I think it's to make a brute-force attempt to guess your password take longer
than it would otherwise.  It's very useful against net-based attacks; I'm not
sure it's necessary for local logins.

Yes, thats what's happening - it a general PAM setting.  There is a yast
setting, Security and Users -> Local Security, "Delay after Incorrect Login
Attempt".  Changing the default is a yast team and security team issue.  I
personally think 3 seconds is too high.

Well, YaST just displays whats in the sysconfig file.  I'm not aware that YaST 
actually defines this value. 

It's FAIL_DELAY in /etc/login.defs -> Thorsten, what do you think about changing
the default value?

Do I get this right? This is an enhancement according to the standard-value of
LOGIN_DELAY in /etc/login.defs?

Actually, the default-value was always 3 seconds as long as I can think... but
indeed one of the first things I ordinarily do after an installation is to
reduce this value. Because for normal purposes it _is_ to high.

Would nice to lower this value to, let's say, 1? Assigning this to the
yast2-security-maintainer.

I'm all for changing the value, but the wait in gnome-screensaver is definitely
longer than 3 seconds.  I just typed in the wrong password twice (purposely) and
counted the time it took.  With a slow count I got 11 and 15 seconds.  I can
time it more accurately if you like, but it seems there is something else
causing a further delay.

I'm not responsible for the default value (YaST doesn't set the default);
Thorsten is.

If somebody does not like the default, he can change it. Since there always a
few people who don't like a default, I will not change it.

Ok... Thorsten, I don't think this has anything to do with the FAIL_DELAY value,
so don't worry about that.  I just changed the FAIL_DELAY value to 4, 1, 0 and
even 30(!), and there was absolutely no affect what so ever.  Afaict this has
nothing to do with FAIL_DELAY.

In addition, I timed the delay slightly more accurately by using a stop watch. 
Without fail it took about 11.14 seconds to return the message of "Password
check failed!".  That is timing from the time I press the [ Enter ] key on the
keyboard to the time I get that message.  There is something else going on here.

So we should adjust the rest of the report.

gnome-screensaver (and xscreensaver) fail over to also trying the root password,
which would add additional time.

That doesn't really explain why it seems to ignore FAIL_DELAY, does it?

Each attempt would presumably have the failed delay - ie your user and the the
root user.

I misunderstood, you'd already reduced the delay.  Rodrigo, can you check this out?

gnome-screensaver just calls /sbin/unix2_chkpwd command. Maybe that is the one delaying?

Could be - the setup seems a little odd.  man unix2_chkpwd indicates it only works with the pam_unix module - shouldn't we just be using the regular pam stuff?

OTOH, we (suse distro) apparently wrote this support, so I'm not clear on the history here.

IIRC pam_unix2 is more versatile (NIS+ etc) and not as broken as pam_unix according to it's author. One major application visible difference between the two is that pam_unix2 does not fork authentication helpers by itself to read eg /etc/shadow. You always have to call pam_unix2 with sufficient permissions. Therefore the setgid shadow unix2_chkpwd helper is used. The helper is really only suitable for simple password based authentication though, it doesn't offer a full pam interface.

The fact that it doesn't offer a full pam interface leads me to believe we should no longer be using it because of upcoming active directory and edir support for logins (among other things).

*** Bug 152357 has been marked as a duplicate of this bug. ***

This is fixed in upstream g-s which is now submitted to autobuild