Why is there a big delay after entering a wrong password?

Question

I notice a weird (well, according to me) thing about passwords. For example, if I type an incorrect password during login, there will be a few seconds' delay before the system tells me so. When I try to sudo with a wrong password I would also have to wait before the shell says "Sorry, try again".

I wonder why it takes so long to "recognize" an incorrect password? This has been seen on several distributions I use (and even OSX), so I think it's not a distribution specific thing.

I have noticed this not only in terminal but also on initial session login after startup or when the laptop is in sleep mode. Unlocking on right password is instantaneous though, happy to see this questions raised :) — krozaine, Jul 12 '18 at 11:28

score 111 · Accepted Answer · edited Jun 01 '21 at 16:51

111

This is a security thing, it's not actually taking long to realize it. 2 vulnerabilities this solves:

this throttles login attempts, meaning someone can't pound the system as fast as it can go trying to crack it (1M attempts a sec? I don't know).
If it did it as soon as it verified your credentials were incorrect, you could use the amount of time it took for it to invalidate your credentials to help guess if part of your credentials were correct, dramatically reducing the guessing time.

to prevent these 2 things the system just takes a certain amount of time to do it, I think you can configure the wait time with PAM ( see Michael's answer ).

Security Engineering ( 3rd ed., Amazon | 2nd ed., free ) gives a much better explanation of these problems. See chapter 2 (PDF) — particularly §2.4 and §2.5.3.3.

edited Jun 01 '21 at 16:51

unforgettableidSupportsMonica

139

answered Sep 16 '10 at 05:24

xenoterracide

59,188
74
187
252

7

//offtopic g its not a bug, its a feature ;-) – echox Sep 16 '10 at 08:18
4

Your affiliate link was automatically rewritten to SE's, btw. – Gelatin Sep 18 '10 at 20:50
@Simon yeah I noticed that... very selfish of them when it's me doing the work. I changed the text of the link since it's not really mine... to lazy to actually change the link though – xenoterracide Sep 18 '10 at 20:57
@xeno The 2nd point isn't clear. I don't understand what you are trying to say. Do you mind rephrasing it? – tshepang Dec 01 '10 at 11:11
@tshepang yes I do, if you need a more comprehensive answer I suggest reading security engineering which spends more than a page explaining the concept to you. – xenoterracide Dec 01 '10 at 13:14
Please read this again: "you can use the amount of time it takes for it to invalidate you help guess if part of your credentials are correct". Aren't you missing something there? – tshepang Dec 01 '10 at 13:24
@tshepang slightly reworded for grammar... but the overall concept is fairly in depth and thus better left to books like security engineering. I think there like a 5 page story explaining #2 in the book. – xenoterracide Dec 01 '10 at 13:33
I still don't get it. Which section of the book talks about this. I gave it a scan and couldn't find it. – tshepang Dec 01 '10 at 14:48
1

@Tshepang: See chapter 2, particularly §2.4 and §2.5.3.3. – Gilles 'SO- stop being evil' Dec 01 '10 at 18:42
@xenoterracide: I don't fully agree with your second point. A good engineering principle for cryptographic operations is that all denials must take exactly the same time (and use as much power, etc.). If the delays are different, the attacker could still differentiate 1ms+1s from 2ms+1s. (Even a random delay wouldn't help that much: the attacker could average the delays out over several attempts.) This is not so important in practice for unix password authentication (where the random fluctuations would take many tries to average out), but does come up in other contexts (e.g. credit card PINs). – Gilles 'SO- stop being evil' Dec 01 '10 at 18:51
@Gilles I guess you are referring to 2nd edition. The free 1st edition doesn't correspond. – tshepang Dec 01 '10 at 22:37
1

@Gilles eh... it probably depends on a lot of things... and I'm sure it's more important of an attack against systems auth-ing against plain text vs those auth-ing against a hash. But that being said doesn't make it a good idea to not implement a wait between tries. – xenoterracide Dec 01 '10 at 23:02
@Tshepang: Yes, 2nd ed (whose ch.2 is online). @xenoterracide: a delay is necessary for reason #1 (attempt rate limiting). It's not an effective countermeasure for reason #2 (it doesn't do much to remove the side channel of response time). – Gilles 'SO- stop being evil' Dec 02 '10 at 00:49
1

Ad 2.: This should not make any difference for hashed passwords (read: for all modern Unices). – rozcietrzewiacz Sep 02 '11 at 10:30
12

The difference between early and late failure while comparing a password hash is measured in nanoseconds. With proper coding(constant time memory comparison) there is no difference at all. That's no justification for adding a delay. – CodesInChaos Mar 23 '13 at 08:50
5

I agree with CodesInChaos: The second point of the answer is incorrect. What is actually happening is the following: 1. a hash of your input is calculated; 2. that hash is compared to the stored hash (every byte of it, even if a difference was already found); Notice, that these two steps are in no way faster or slower depending on whether the password you entered was correct. (and as others have already pointed out, adding a sleep duration would not fix a timing attack if it were possible) – example Jul 20 '15 at 09:35
1

Using a constant-time string comparison function to compare hashed passwords is completely orthogonal to the question of adding extra delay. After all, we are talking about sudo, not a remote attack, so quantizing the time is not very useful if you are just sleeping, thereby detectably releasing the CPU. That said, this isn't a serious an issue because you are comparing password hashes and the salt is unknown (unlike, say Tenex which used to compare actual passwords). Therefore the second part of this answer is badly misleading. – user3188445 Dec 28 '16 at 01:42
My linux has the lag regardless of whether the password is correct or not. Is there any security reason for that? – B T Oct 04 '18 at 18:20
Validation of the correct password should take the same time. Adding a delay makes no sense and actually proves its a weak algorithm. Bruteforcing it is about the algorithm you could easily run a decoder without the artificial delay for brute forcing. It should be about computational complexity which needs to increase when processors get faster. – Wouter Jul 31 '20 at 23:25

score 49 · Answer 2 · answered Sep 16 '10 at 05:29

49

This is intentional, to try and limit brute forcing. You can usually modify it by looking for the FAIL_DELAY configuration entry in /etc/login.defs and changing its value (mine is 3 seconds by default), although the comment in that file makes it sound like PAM will enforce at least a 2 second delay no matter what

answered Sep 16 '10 at 05:29

Michael Mrozek

93,103
40
240
233

10

This is to prevent more than just brute forcing. but bonus points for knowing where to configure it. – xenoterracide Sep 16 '10 at 05:33
6

I think that the fail_delay is also configurable in /etc/pam.d/login. Look for pam_faildelay.so delay= – Steven D Sep 16 '10 at 05:40
15

what prevents you from writing a wrapper for sudo that starts a new sudo instance once an attempt doesn't work within, say, 0.1 secs? – Janus Troelsen Nov 20 '14 at 16:35
2

@xenoterracide What more? – Wouter Jul 31 '20 at 23:28

score 24 · Answer 3 · answered Jul 03 '15 at 00:32

On modern linux systems, the reason is that pam_unix.so imposes such a delay. As previously reported, this can be configured down to two seconds by changing FAIL_DELAY in /etc/login.defs. If you want to reduce the delay further, you have to give pam_unix.so the "nodelay" option. For example, on my system, if you trace the includes starting from /etc/pam.d/sudo, you find you have to edit the following line of /etc/pam.d/system-auth:

auth      required  pam_unix.so     try_first_pass nullok

and change it to this:

auth      required  pam_unix.so     try_first_pass nullok nodelay

Unfortunately, the way my linux distro (arch) configures things, that very same system-auth file gets included by system-remote-login, which is used by sshd.

While it is safe to eliminate the delay on sudo, because that is logged, only used by local users, and bypassable by local attackers anyway, you probably don't want to eliminate this delay for remote logins. You can of course fix it by writing a custom sudo that doesn't just include the shared system-auth files.

Personally, I think the delay on sudo (and ignoring SIGINT) is a big mistake. It means users who know they mistyped the password can't kill the process and get frustrated. Of course, you still can stop sudo with Ctrl-Z, as sudo doesn't catch SIGTSTP, and after stopping it you can kill it with kill -9 (SIGKILL). It's just annoying to do. So that means an automated attack could fire off sudos on pseudo-terminals at a super high rate. But the delay frustrates legitimate users and encourages them to suspend their root shells instead of exiting them to avoid having to sudo again.

Brilliant answer. I was also thinking FAIL_DELAY has become obsolete in modern Desktop systems. You should rely on partition / hard drive encryption and nothing else. Typically, there is no second user who might try to brute force root password. However, potentially malicious programs could abuse an insecure FAIL_DELAY and thus get root access. — phil294, Jun 21 '18 at 15:14
setting pam-unix to nodelay will set the wait time to 0 by the way, and FAIL_DELAY is then ignored. — phil294, Jun 21 '18 at 15:20
Why not disable the delay, and then disable remote password login (SSH-only)? Doesn't that solve the problem without introducing any security vulnerability? — Resigned June 2023, Jan 07 '19 at 03:20
I use manjaro and some time ago there was a problem with my sudo setup and after typing the wrong password multiple times in a tty,my user account got locked,so I resorted to passwd -u to unlock it.Is this the case with SSH remote logins? I mean if an account gets locked after a few attempts with the wrong passwords,then there should be no security vulnerability concerning brute-force attacks.I think that has nothing to do with nodelay.Please correct me if I'm wrong. — Parsa Mousavi, Dec 18 '20 at 22:10

Why is there a big delay after entering a wrong password?

3 Answers3

Linked

Related