111

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.

Improve this question
1
  • 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, 2018 at 11:28

3 Answers 3

Reset to default
110

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

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

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

Improve this answer
19
  • 7
    //offtopic g its not a bug, its a feature ;-)
    – echox
    Sep 16, 2010 at 8:18
  • 4
    Your affiliate link was automatically rewritten to SE's, btw.
    – Gelatin
    Sep 18, 2010 at 20:50
  • 1
    @Tshepang: See chapter 2, particularly §2.4 and §2.5.3.3.
    – Gilles 'SO- stop being evil'
    Dec 1, 2010 at 18:42
  • 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, 2013 at 8: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, 2015 at 9:35
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

Improve this answer
4
  • 10
    This is to prevent more than just brute forcing. but bonus points for knowing where to configure it.
    – xenoterracide
    Sep 16, 2010 at 5: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, 2010 at 5: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, 2014 at 16:35
  • 1
    @xenoterracide What more?
    – Wouter
    Jul 31, 2020 at 23:28
21

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.

Improve this answer
6
  • 2
    Same with Fedora. Awesome analysis
    – Freedom_Ben
    Jul 29, 2016 at 4:27
  • 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, 2018 at 15:14
  • 1
    setting pam-unix to nodelay will set the wait time to 0 by the way, and FAIL_DELAY is then ignored.
    – phil294
    Jun 21, 2018 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 7, 2019 at 3: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, 2020 at 22:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .