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?

Security feature to stymie brute-force logins

1 members found this post helpful.

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

1 members found this post helpful.

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?

Yes there are such ways.

Markus

0 members found this post helpful.

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.

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).

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.

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.