touch-packages team mailing list archive

[Mike Doherty <mike@xxxxxxxxxxxxxx>]

(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