Public bug reported:
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.
** Affects: sudo (Ubuntu)
Importance: Undecided
Status: New
--
Annoying and useless delays on password entry errors
https://bugs.launchpad.net/bugs/138654
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
