Why should checking a wrong password take longer than checking the right one?

It's actually to prevent brute force attacks from trying millions of passwords per second. The idea is to limit how fast passwords can be checked and there are a number of rules that should be followed.

• A successful user/password pair should succeed immediately.
• There should be no discernible difference in reasons for failure that can be detected.

That last one is particularly important. It means no helpful messages like:

Your user name is correct but your password is wrong, please try again

or:

Sorry, password wasn't long enough

Not even a time difference in response between the "invalid user and password" and "valid user but invalid password" failure reasons.

Every failure should deliver exactly the same information, textual and otherwise.

Some systems take it even further, increasing the delay with each failure, or only allowing three failures then having a massive delay before allowing a retry.

This makes it take longer to guess passwords.

I am not sure, but it is quite common to integrate a delay after entering a wrong password to make attacks harder. This makes a attack practicaly infeasible, because it will take you a long time to check only a few passwords.

Even trying a few passwords - birthdates, the name of the cat, and things like that - is turned into no fun.

Basically to mitigate against brute force and dictionary attacks.

From The Linux-PAM Application Developer's Guide:

Planning for delays

extern int pam_fail_delay(pam_handle_t *pamh, unsigned int micro_sec);

This function is offered by Linux-PAM to facilitate time delays following a failed call to pam_authenticate() and before control is returned to the application. When using this function the application programmer should check if it is available with,

#ifdef PAM_FAIL_DELAY
    ....
#endif /* PAM_FAIL_DELAY */

Generally, an application requests that a user is authenticated by Linux-PAM through a call to pam_authenticate() or pam_chauthtok(). These functions call each of the stacked authentication modules listed in the relevant Linux-PAM configuration file. As directed by this file, one of more of the modules may fail causing the pam_...() call to return an error. It is desirable for there to also be a pause before the application continues. The principal reason for such a delay is security: a delay acts to discourage brute force dictionary attacks primarily, but also helps hinder timed (covert channel) attacks.

It's a very simple, virtually effortless way to greatly increase security. Consider:

1. System A has no delay. An attacker has a program that creates username/password combinations. At a rate of thousands of attempts per minute, it takes only a few hours to try every combination and record all successful logins.

2. System B generates a 5-second delay after each incorrect guess. The attacker's efficiency has been reduced to 12 attempts per minute, effectively crippling the brute-force attack. Instead of hours, it can take months to find a valid login. If hackers were that patient, they'd go legit. :-)

Failed authentification delays are there to reduce the rate of login attempt. The idea that if somebody is trying a dictionary or a brute force attack against one or may user accounts that attacker will be required to wait the fail delay and thus forcing him to take more time and giving you more chance to detect it.

You might also be interested in knowing that, depending on what you are using as a login shell there is usually a way to configure this delay.

In GDM, the delay is set in the gdm.conf file (usually in /etc/gdm/gdm.conf). you need to set RetryDelay=x where x is a value in seconds.

Most linux distribution these day also support having FAIL_DELAY defined in /etc/login.defs allowing you to set a wait time after a failed login attempt.

Finally, PAM also allows you to set a nodelay attribute on your auth line to bypass the fail delay. (Here's an article on PAM and linux)

I don't see that it can be as simple as the responses suggest.

If response to a correct password is (some value of) immediate, don't you only have to wait until longer than that value to know the password is wrong? (at least know probabilistically, which is fine for cracking purposes) And anyway you'd be running this attack in parallel... is this all one big DoS welcome mat?