LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   Why does it take ages to re-enter the password in linux login screens? (http://www.linuxquestions.org/questions/linux-security-4/why-does-it-take-ages-to-re-enter-the-password-in-linux-login-screens-887939/)

ranban282 06-23-2011 09:39 AM

Why does it take ages to re-enter the password in linux login screens?
 
When I try to log in to virtually any linux system through the gui, and I enter the correct password, the desktop initialization starts immediately. But when the password entered is incorrect, it takes a couple of seconds to say that the password is incorrect, and another second or so before I can enter my password again.I have seen this in ubuntu 10.04 and various versions of fedora. Any clues?

AlucardZero 06-23-2011 09:49 AM

Security feature to stymie brute-force logins

MTK358 06-23-2011 11:28 AM

Quote:

Originally Posted by ranban282 (Post 4393753)
Any clues?

It's actually a security feature to slow down password crackers that try to enter different passwords until one happens to match.

ranban282 07-03-2011 01:17 PM

From a security point of view, how would it be if 3 successive attempts had no delay and exponential delays thereafter?

Second question - Since we are talking about a login screen, we are talking about manual brute-force attempts, right? Or is there some automated way to brute-force?

markush 07-03-2011 01:30 PM

Quote:

Originally Posted by ranban282 (Post 4403544)
...
Second question - Since we are talking about a login screen, we are talking about manual brute-force attempts, right? Or is there some automated way to brute-force?

Yes there are such ways.

Markus

win32sux 07-03-2011 11:14 PM

Quote:

Originally Posted by ranban282 (Post 4403544)
From a security point of view, how would it be if 3 successive attempts had no delay and exponential delays thereafter?

Well, you'd have to do the math to know for sure, but in all honestly it sounds to me like it could be a reasonable approach for some people. I mean, as long as the exponential delay doesn't reach the point where this can be used to DoS someone, of course.

Quote:

Second question - Since we are talking about a login screen, we are talking about manual brute-force attempts, right? Or is there some automated way to brute-force?
Yeah, it wouldn't take a rocket scientist to use a computer (be it hand-held, PC, smartphone, whatever) to hook up via USB and spoof a keyboard (which will use automation to brute-force).

Nominal Animal 07-04-2011 04:20 AM

Quote:

Originally Posted by ranban282 (Post 4403544)
From a security point of view, how would it be if 3 successive attempts had no delay and exponential delays thereafter?

There are two sources for the delay in current Linux distributions: Pluggable Authentication Module pam_faildelay (usually configured in /etc/pam.d/login, but may vary between distributions), and the failure delay requested by PAM applications themselves via the pam_fail_delay() function. (Of course login programs can do additional delays, but e.g. gdm-2.30.6 does not. The only delay it has is an exponential backoff when it cannot connect to the X server, but that has nothing to do with login failures.)

The reason pam_faildelay implements a fixed delay is that there really is no state shared between different login attempts. That means there is no notion of "succession", or of when or if another attempt succeeded or failed. Each attempt is a separate event, independent of all others. The PAM architecture is such that sharing state between authentication attempts is not easy. To implement different delay levels, some kind of shared state is needed.

I believe it would not be worth the effort.

Perhaps you could just tune down the delay a bit in your /etc/pam.d/login file? The delay= option contains the failure delay in microseconds, 1000000Ás=1s.

Quote:

Originally Posted by ranban282 (Post 4403544)
Second question - Since we are talking about a login screen, we are talking about manual brute-force attempts, right? Or is there some automated way to brute-force?

Yes, there is, and it costs maybe 20 USD, and works with any USB HID (Human Interface Device), as long as you can write for example a compact C program that generates the HID event data.

Fortunately, even a one second delay per failed attempt -- whether password or some other method like fingerprinting -- does make any such device pretty much impotent. You cannot really say they won't work, because they might, if there are few enough candidates. A three-day weekend has a quarter of a million seconds, so having a strong password is still important.


All times are GMT -5. The time now is 11:50 AM.