So,
When I try to login with my username and password (in tty), and insert a wrong password, I need to wait around 5 seconds for the system to tell me that the password is wrong.
Why the validating process is taking that long?
GNU/Linux disto: Archlinux.
Adding a little bit of historical perspective, the idea of sleeping after a bad password is not just found in PAM-based systems. It's very old. For eaxmple in the 4.4BSD login source you'll find this tasty fragment:
/* we allow 10 tries, but after 3 we start backing off */
if (++cnt > 3) {
if (cnt >= 10) {
badlogin(username);
sleepexit(1);
}
sleep((u_int)((cnt - 3) * 5));
}
so the first 3 failures are free, the next 7 have increasing delays (5 seconds, 10 seconds, 15 seconds...) and after 10 it does a sleepexit(1) which is a 5 second delay followed by an exit(1).
The sleeps are just an annoyance when you're typing a password on the console, but they're important when the input is coming from a remote user who might be automating the process.
The sleepexit after 10 failures deserves special explanation. After login exits, getty just prints another login prompt and starts the cycle again. So why sleep and exit instead of just sleeping? Because when this feature was introduced, login over dialup was common. (Note for people who never used a modem before 1995: I said login over dialup, not PPP or other packet-based protocol over dialup. You'd dial a number in a terminal emulator and get a login prompt.)
In the dialup world, anybody could just dial your number and start throwing passwords at it, so the login process exited after a few bad passwords, causing the modem connection to terminate, forcing them to redial before they could try more passwords. The same principle applies to ssh today (configuration option MaxAuthTries) but it was more effective in the old days, because dialing a modem was quite a bit slower than a TCP handshake.
See this answer on StackOverflow that quotes the The Linux-PAM Module Writers' Guide:
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.
The pam_fail_delay() function provides the mechanism by which an application or module can suggest a minimum delay (of micro_sec micro-seconds). Linux-PAM keeps a record of the longest time requested with this function. Should pam_authenticate() fail, the failing return to the application is delayed by an amount of time randomly distributed (by up to 25%) about this longest value.
Independent of success, the delay time is reset to its zero default value when Linux-PAM returns control to the application.
As others have answered, PAM is most likely the cause for this. The actual verification of the password only takes a very short time, the rest is a delay designed to prevent brute force attacks. On Debian, I have the following lines in /etc/pam.d/login:
# Enforce a minimal delay in case of failure (in microseconds).
# (Replaces the `FAIL_DELAY' setting from login.defs)
# Note that other modules may require another minimal delay. (for example,
# to disable any delay, you should add the nodelay option to pam_unix)
auth optional pam_faildelay.so delay=3000000
If the 5 second delay is too long (certainly having to wait for this time if you are in a hurry can feel like it is too long), you could always shorten the time by looking for the equivalent file on your system. If you don't have PAM, as the comment in the snippet above says, you could look under /etc/login.defs for the FAIL_DELAY value.
I don't use Archlinux myself, so I don't know exactly, but this sounds like a mechanism against brute-force password guessing.
