Binary package hint: sudo
Hello! This is about Ubuntu Gutsy, though it applies to the other versions as well.
My problem is that every password-entry that requires the user's log-in password has an annoying little delay of a few seconds when entering a mistaken password before asking again for it. (I linked sudo above, but this applies to the login on the console and on the GDM screen, the screen-savers, gksu I think, and I'm sure I forget some. SSH does this too, I think, but I've been using public-key logins for too long and I forget.)
Example: run "sudo ls" in a terminal, type a wrong password, and watch how you're forced to wait before being told it's wrong and asked to try again.
I think this is supposed to be a security feature attempting to discourage brute-forcing a password. However, it's annoyingly intrusive, and I doubt it's that effective or useful in many cases. (Though I must agree it's relatively simple.)
First of all, this isn't really as effective a security measure as it might seem: For most cases it's very simple to get around this by attempting a password, killing the process after 100ms if it doesn't answer and retrying. This effectively reduces the time cost for an attempt to $PROCESS_START_TIME+$PASSWORD_ENTRY_TIME+100ms, which is typically much less than the three or so seconds sudo forces a user to wait. For instance, if I'd try to use sudo to brute force a password I'd run "sudo echo 'found it'" (to make sure I get the answer quickly) in a loop, killing the process 100ms after entering a password attempt and not receiving any output.
Granted, there's the added time cost of re-starting the process, but every password entry fails after three errors, so simply removing the delay would decrease the brute-force time by at most a factor of three. Which isn't really much, is it?
First proposal: given the above attack, I suggest lowering the delay to about half a second. This would make brute force about five time easier than it is now (which I believe isn't a great concern), and would be almost unnoticeable by a normal user.
Second proposal: the system should keep for each password a global count of recent failures. Any anti-brute-force measures should be activated only when the number of consecutive failures grows. The counter would be reset on success, and would decay in time.
This second proposal is I think optimal. It sounds a bit complicated. However, I believe all the programs above actually make use of common PAM modules (also, I think the delay is controlled by those), so this would be easy to implement just once.
Note that every element of the second proposal is important: the counters must be per-machine global, not per-process or per-session (so an attacker can't just kill a process and retry), and there must be separate counters for each password (so you can't reset it by entering a known password, and an attempt to brute-force one user's password doesn't inconvenience other users).
Note also that this scheme is both more protective and convenient:
(a) the delay can grow with the number of attempts, eg. 3 secs after three failures, 10 secs after twenty failures, one minute and a big nasty warning after a hundred consecutive failures. (This way, a legitimate user would notice something is amiss instead of just resetting the counter.)
(b) the measures are activated even if the attacker tries to use the technique above. Even if he kills the process, he'll still get the delay _even for the first attempt_ after several errors.
(c) users don't have to wait each time they make a typo in a password entry field.
After a bit more reading-up I see most of this should be possible by simply updating the default configuration in /etc/pam.d
The delay can be removed by adding parameter to common-auth's pam_unix, and the counting by using pam_tally. I can't figure out how to add a growing timeout; perhaps a new module is needed, that might need a new module.
I'm moving this to pam-runtime, as it's a PAM configuration issue rather than a sudo problem. I see pam-runtime owns /etc/pam.d/other, but I can't figure out which package owns the /etc/pam.d/common-* files; pam-runtime has them listed in /usr/share/pam, but I don't know how they get into /etc/pam.d. Please leave a note if you know.