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

Question

This question has always troubled me.

On Linux, when asked for a password, if your input is the correct one, it checks right away, with almost no delay. But, on the other hand, if you type the wrong password, it takes longer to check. Why is that?

I observed this in all Linux distributions I've ever tried.

Lean

You will find this to be true of Windows as well. Also, changing the Title to something like, "Why have wrong passwords take longer than correct ones." Would make it more programming related. – Pollack

I just logged into my Ubuntu system, entered the wrong password and asked myself the same question. :-) – Ghost

Answer 1

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.

Atwitter

How does this prevent an app from forking, trying a password, and if it doesn't return success in some amount of time, kill -9 the child and fork again. Yes that only works if you can log in as some user but when has that stopped anyone? – Upu

It doesn't stop anyone but you still have to delay for that "some amount of time". Even a tiny delay makes checking millions of passwords useless, and you will be detected if you're doing it while logged on - do you think nothing is logged for failed logins? – Atwitter

BCS: if you already have a valid login with enough privileges to do what you propose, chances are that you no longer need brute force attacks (because there are other attack vectors available to you). The delay is most useful against external attackers. – Oscoumbrian

Answer 2

This makes it take longer to guess passwords.

Seabury

Answer 3

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.

Hand

And often the timeout on the second failure is longer than the timeout on the first - which is good too. – Diamagnet

Did you see the news post about the most likely passwords? 123456 is very very popular! – Pazia

@Spence, I actually did see those items but, from memory, it's not as bad as people made out, they were (as the media are wont to do) blowing it out of proportion. The passwords were drawn from lists of compromised accounts found on-line, meaning that they're far more likely to be insecure (because they were compromised). 123456 could well make up 30% (for example) of compromised accounts but is unlikely to be anywhere near that significant across all accounts. – Atwitter

No, those lists are from password database hacks and most of them represent sample sets in the millions. The results from these hacks have been confirmed across multiple online datasets and are highly representative of the "average" consumer. Only way to get better passwords is to enforce it at creation, or better yet use 2 factor authentication which is far more useful anyway. – Pazia

Answer 4

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.

Logy

Answer 5

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

Wallet

Answer 6

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)

Tharpe

Answer 7

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?

Decal

that's not what they meant. there is an obvious difference between getting the password wrong, or right. what they meant was that there should be no difference between an incorrect username, and an incorrect password. and do you mean running this attack in parallel? how can you run it in parallel? – Spiral

@Mark, running in parallel probably would entail opening multiple connections and trying to login. Still time consuming and not very practical. – Pollack

If you can run a million checks per second on a non-slowed connection and the connection then has a 1-second delay added for failed attempts, you'd need a million attack clients to get the same effect. I doubt the server will allow that many telnet sessions to be created. – Atwitter

the point is you don't have to wait out the delay before you try the next password, so what's the use? – Decal

@Greg, you do have to re-connect to the host and, if necessary, the next step would be to check IP addresses to catch this as well. – Atwitter

Or just have successful attempts take a second as well. You don't log on often enough for that to be a problem but it would be for an attack node. – Atwitter

@Pax: yes of course, but without the next step what's the point? – Decal

@All: Remember that it takes time to establish a network connection, so it's far more efficient to "piggyback" several attempts on one (network) session than to try once, disconnect, reconnect, try again, da capa ad infinitum. A good system will disconnect a user after a small number of failures. – Wallet

Answer 8

On Ubuntu 9.10, and I think new versions too, the file you're looking for is located on

/etc/pam.d/login

edit the line:

auth optional pam_faildelay.so delay=3000000

changing the number 3 with another you may want.

Note that to have a 'nodelay' authentication, I THINK you should edit the file

/etc/pam.d/common-auth

too. On the line:

auth [success=1 default=ignore] pam_unix.so nullok_secure

add 'nodelay' to the final (without quotes). But this final explanation about the 'nodelay' is what I think.

Distrait

Answer 9

What I tried before appeared to work, but actually did not; if you care you must review the wiki edit history...

What does work (for me) is, to both lower the value of pam_faildelay.so delay=X in /etc/pam.d/login (I lowered it to 500000, half a second), and also add nodelay (preceded by a space) to the end of the line in common-auth, as described by Gabriel in his answer.

auth [success=1 default=ignore] pam_unix.so nullok_secure nodelay

At least for me (debian sid), only making one of these changes will not shorten the delay appreciably below the default 3 seconds, although it is possible to lengthen the delay by only changing the value in /etc/pam.d/login.

This kind of crap is enough to make a grown man cry!

Tameratamerlane

Answer 10

I would like to add a note from a developers perspective. Though this wouldn't be obvious to the naked eye a smart developer would break out of a match query when the match is found. In witness, a successful match would complete faster than a failed match. Because, the matching function would compare the credentials to all known accounts until it finds the correct match. In other words, let's say there are 1,000,000 user accounts in order by IDs; 001, 002, 003 and so on. Your ID is 43,001. So, when you put in a correct username and password, the scan stops at 43,001 and logs you in. If your credentials are incorrect then it scans all 1,000,000 records. The difference in processing time on a dual core server might be in the milliseconds. On Windows Vista with 5 user accounts it would be in the nanoseconds.

Talmud

I think you'll find 99% of the posters here are developers of one level or another. Stop sounding so pompous. – Amaleta

I use Ubuntu and there is only one user. However, when i submit a wrong password it takes 3 seconds for me to get a response. So, you are wrong :) – Paraldehyde

Answer 11

I agree. This is an arbitrary programming decision. Putting the delay to one second instead of three doesn't really hurt the crackability of the password, but makes it more user-friendly.

Brickbat

Answer 12

Technically, this deliberate delay is to prevent attacks like the "Linearization attack" (there are other attacks and reasons as well).

To illustrate the attack, consider a program (without this deliberate delay), which checks an entered serial to see whether it matches the correct serial, which in this case happens to be "xyba". For efficiency, the programmer decided to check one character at a time and to exit as soon as an incorrect character is found, before beginning the lengths are also checked.

The correct serial length will take longer to process than an incorrect serial length. Even better (for attacker), a serial number that has the first character correct will take longer than any that has an incorrect first character. The successive steps in waiting time is because each time there's one more loop, comparison to go through on correct input.

• So, attacker can select a four-character string and that the string beginning with x takes the most time. (by guess work)
• Attacker can then fix character as x and vary the second character, in which case they will find that y takes the longest.
• Attacker can then fix the first two characters as xy and vary the third character, in which case they will find that b takes the longest.
• Attacker can then fix the first three character as xyb and vary the fourth character,in which case they will find that a takes the longest.

Hence, the attackers can recover the serial one character at a time.

Linearization.java.

Linearization.docx, sample output

The serial number is four characters long ans each character has 128 possible values. Then there are 128⁴ = 2²⁸ = 268,435,456 possible serials. If attacker must randomly guess complete serial numbers, she would guess the serial number in about 2²⁷ = 134,217,728 tries, which is an enormous amount of work. On the other hand, by using the linearization attack above, an average of only 128/2 = 64 guesses are required for each letter, for a total expected work of about 4 * 64 = 2⁸ = 256 guesses, which is a trivial amount of work.

Much of the written martial is adapted from this (taken from Mark Stamp's "Information Security: Principles and Practice"). Also the calculations above do not take into account the amount of guesswork needed to to figure out the correct serial length.

Explain

Answer 13

To remove this behavior in Ubuntu 22.04:

sudoedit /etc/pam.d/common-auth

find the following line:

auth [success=2 default=ignore] pam_unix.so nullok

add nodelay at the end:

auth [success=2 default=ignore] pam_unix.so nullok nodelay

Jorin