(Just a reminder that when combined with bug 1308265, it can get pretty annoying. This is worth fixing.)
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/138654 Title: Annoying and useless delays on password entry errors Status in Ubuntu: Invalid Status in pam package in Ubuntu: Triaged Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/138654/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp